another fpc RAD: MSEide

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re[2]: another fpc RAD: MSEide

Michael Van Canneyt


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

Try downloading them over a 56k modem ;-)

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: another fpc RAD: MSEide

Marco van de Voort
> 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...
>
> 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"?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: another fpc RAD: MSEide

Michael Van Canneyt


On Wed, 19 Apr 2006, Marco van de Voort wrote:

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

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: another fpc RAD: MSEide

Marco van de Voort
> On Wed, 19 Apr 2006, Marco van de Voort wrote:
>
> >> 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...
> >>
> >> 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"?
>
> 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.

I know, see the faq about binary sizes

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

"modem distribution"

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Matt Emson
In reply to this post by Florian Klaempfl
> 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.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

L505
In reply to this post by Micha Nelissen




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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Peter Vreman
At 17:22 19-4-2006, you wrote:




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

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Micha Nelissen
In reply to this post by Matt Emson
On Wed, 19 Apr 2006 10:42:05 +0100
"Matt Emson" <[hidden email]> wrote:

> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: another fpc RAD: MSEide

L505
In reply to this post by Michael Van Canneyt


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

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.

> >
> > Speaking of bigger applications, I don't see much difference between 6 or 30
> Mb executables...
>
> Try downloading them over a 56k modem ;-)
>

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. )
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: another fpc RAD: MSEide

Michael Van Canneyt


On Wed, 19 Apr 2006, L505 wrote:

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

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: another fpc RAD: MSEide

L505
In reply to this post by Marco van de Voort


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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Florian Klaempfl
In reply to this post by Matt Emson
Matt Emson wrote:
>> 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.

Well, compared with other commercial compilers it is broken ;)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Florian Klaempfl
In reply to this post by L505
L505 wrote:
>
> 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.

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: another fpc RAD: MSEide

L505
In reply to this post by Michael Van Canneyt
> > 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.
>
> 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.

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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

L505
In reply to this post by Florian Klaempfl


> L505 wrote:
> >
> > 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.
>
> 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.

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Matt Emson
In reply to this post by Micha Nelissen
> > 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.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: another fpc RAD: MSEide

Michael Van Canneyt
In reply to this post by L505


On Wed, 19 Apr 2006, L505 wrote:

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

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Florian Klaempfl
In reply to this post by L505
L505 wrote:

>
>> L505 wrote:
>>> 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.
>> 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.
>
> There was also USCD pascal .. but people complained it was too slow?

Yes. That's the drawback :) Ever had a look at the executable size of
the Intel C compiler if you optimize for speed?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Florian Klaempfl
In reply to this post by L505
L505 wrote:

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

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: another fpc RAD: MSEide

Matt Emson
In reply to this post by Florian Klaempfl
> > 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? ;-)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
123