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
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
Micha Nelissen schreef:
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
Hello All,
Would'nt it be a good idea to register for the google soc? It is a
good way to attract developers and get things done quickly.
Cheers,
Krishna
--
You think you know when you learn, are more
sure when you can write, even more when you
can teach, but certain when you can program
- Alan
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
On 18 apr 2006, at 22:53, Adrian Maier wrote:
NetBSD is not on fpc's list of supported operating systems,
although there
is an older version available (1.0.10) which works fine, at least
for my
purposes.
I've tried to compile the latest sources (svn), but :
system.pp(23,6) Error:
On Wednesday 19 April 2006 10.33, Micha Nelissen wrote:
Martin Schreiber wrote:
mseide without DB support:ziped
Are you afraid to draw conclusions?
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
NetBSD is not on fpc's list of supported operating systems, although there
is an older version available (1.0.10) which works fine, at least for my
purposes.
Currently there is none. 1.9.2 had NetBSD/macppc support for a while, but it
wasn't maintained.
I've tried to compile the latest
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
On Wed, 19 Apr 2006, Matt Emson wrote:
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.
The
Micha Nelissen schreef:
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) ?
It can see the advantages and they should not be diminished:
- having different compilers to confirm or
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.
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
On Wed, 19 Apr 2006, Marco van de Voort wrote:
Micha Nelissen schreef:
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) ?
It can see the advantages and they should not be diminished:
-
On Wednesday 19 April 2006 11.55, Marco van de Voort wrote:
This could be caused by Kylix being able to some
more advanced types of smartlinking due to own linker. (e.g. vtable
optimization)
And I suspect RTTI info.
If your binaries use libc, recompiling FPC with dFPC_USE_LIBC might bring
Win32, i386.
In FPC 2.0.3 -Oa option is described as type=values.
This is hard to understand. What should -Oa=16 mean?
Probably, it could be better decribed.
(If I get it right, the type means code or data, and values are not alignment
values for individual types. Even if so, I didn't
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...
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
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
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
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.
On 19 apr 2006, at 12:13, Пётр Косаревский wrote:
Win32, i386.
In FPC 2.0.3 -Oa option is described as type=values.
This is hard to understand. What should -Oa=16 mean?
Nothing, since you are not giving a type.
Probably, it could be better decribed.
The valid keywords are indeed not yet
On 19 apr 2006, at 17:43, Jonas Maebe wrote:
The valid keywords are indeed not yet documented. Here are the
possibilities (copy/paste from the compiler source):
Forgot one:
if tok='PROC' then
b.procalign:=l
else if tok='JUMP' then
b.jumpalign:=l
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
If you can't find jobs
out there that use Pascal then you have to be really brave and start
your own business and start hiring people with Pascal skills.
Yeah right. Sorry to bring that up again, but if I would do that I would
never hire people that claim to have such specialized skills.
On Wed, 19 Apr 2006 10:42:05 +0100
Matt Emson [EMAIL PROTECTED] 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
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
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
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
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
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
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
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
Okay so we have to now consider these points:
1. interpreted languages can take up less memory if engineered right (says
Florian)
2. compilation and linking is a hassle - compared to shipping or uploading an
interpreted
file
3. speed - not a big deal. Hardware cheap enough.
4. size -
L505 wrote:
Okay so we have to now consider these points:
1. interpreted languages can take up less memory if engineered right (says
Florian)
2. compilation and linking is a hassle - compared to shipping or uploading
an interpreted
file
3. speed - not a big deal. Hardware cheap enough.
On Wed, 19 Apr 2006, L505 wrote:
Okay so we have to now consider these points:
1. interpreted languages can take up less memory if engineered right (says
Florian)
So can compiled. It depends all on your RTL.
I used such languages.
The interpreted languages Florian talks about had less
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
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 -
Matt Emson wrote:
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
On Wed, 19 Apr 2006, I wrote:
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
3. speed - not a big deal. Hardware cheap enough.
Speed definitely does matter for some apps: application servers,
database servers etc. So you can't generalize this.
I'll have to agree with the second comment, not the first.
I use fpc for statistical simulation programs, many of which
L 3. speed - not a big deal. Hardware cheap enough.
If you ship programs, it's not you who decide whether hardware is
cheap.
If you do a small repetitive task several millions times, speed may
easily differ hundred times (for example: compiled piece of code fits into
cache, but interpreted
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
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
3. speed - not a big deal. Hardware cheap enough.
Speed definitely does matter for some apps: application servers,
database servers etc. So you can't generalize this.
This is my view too.. purely playing devils advocate there.. :-)
4. size - shipping an interpreted file usually
-Fu/home/me/project1/units/*.*
No such thing for FPC, right? Recursive units searches?
Could be useful, but dangerous if directories contain different versions of the
source
file in different places.
Still, in many projects I get sick of continually adding new directories to the
search
path -
-Fu/home/me/project1/units/*.*
Is there an existing recursive option like this for -Fu and -Fi?
Could be useful, but dangerous if directories contain different versions of the
source
file in different places.
Still, in many projects I get sick of continually adding new directories to the
47 matches
Mail list logo
