On Thu, 3 Jun 2010, Graeme Geldenhuys wrote:
To get back to the point. So must I now override GetChildren for every
single component in fpGUI that can contain child components and do the
loopy Components[] array thing? Or do I only need to override
GetChildren in TfpgBaseForm - the top
On Fri, 4 Jun 2010 00:33:18 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 3 June 2010 22:55, Mattias Gaertner wrote:
I other words: There are two tree like structures: Owner and Parent.
Parent is optional and will make your stream files more readable.
[...]
Readability.
On Friday 04 June 2010 09:10:28 Graeme Geldenhuys wrote:
I now understand why Martin implemented MSEgui from the ground up and not
basing any code on Borland's ideas. You never need to fight strange
implementations, other than your own. :)
Although you are right in principle, owner/parent
Hello,
I just discovered a set of wiki pages about freepascal's compiler:
http://wiki.lazarus.freepascal.org/FPC_internals. On can find at
http://wiki.lazarus.freepascal.org/Symbol_tables the following table (a bit
refactored here).
The Symbol table object
All symbol tables in the compiler
*** Sorry, I sent this post to the wrong list. Hope you find it interesting
anyway ...
Hello,
I just discovered a set of wiki pages about freepascal's compiler:
http://wiki.lazarus.freepascal.org/FPC_internals. On can find at
http://wiki.lazarus.freepascal.org/Symbol_tables the following
On 04 Jun 2010, at 00:23, José Mejuto wrote:
Thursday, June 3, 2010, 6:51:22 PM, you wrote:
JM Since the RTL is compiled with optimisation enabled, you may
JM be missing intermediate stack frames. You will have to recompile
JM it without optimisations to get a full backtrace.
Done, the halt
On Fri, 04 Jun 2010 08:50:06 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
Borland and Embarcadero jumps off
the cliff - FPC must now also jump off the cliff. :)
Hello, Graeme!
I'm surprised of this, fpc still systematically trying to follow Delphi, after
so many years. I can
Op 2010-06-04 12:54, spir het geskryf:
(including choices of non-implementation), so why not having already
made the step of declaring fpc a (object) Pascal dialect of its own?
I agree 100%. It was all good and well (in the beginning) to try and be a
Delphi clone, but now it makes no real
On Fri, 4 Jun 2010, spir wrote:
On Fri, 04 Jun 2010 08:50:06 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
Borland and Embarcadero jumps off
the cliff - FPC must now also jump off the cliff. :)
Hello, Graeme!
I'm surprised of this, fpc still systematically trying to follow
On Fri, 4 Jun 2010 13:21:09 +0200 (CEST)
Michael Van Canneyt mich...@freepascal.org wrote:
And to be honest, I think we do a very good job of it. Yes, we don't have
100% compatibility. But no, it's never 100%. But it is certainly good
enough to satisfy most people that need it.
Hello,
In our previous episode, Michael Van Canneyt said:
To many people inside and outside the FPC team, a high degree of Delphi
compatibility is a must. For a simple reason: reuse of existing Delphi
code, of which there is infinitely more than FPC code.
(see e.g. also the number of Delphi
Hello FPC-Pascal,
Friday, June 4, 2010, 10:37:42 AM, you wrote:
And this is the backtrace. Any idea ?
JM Maybe you are executing Pascal code in threads that have not been
JM started via the FPC rtl? (i.e., not via beginthread nor via
JM tthread.create) That is not supported on Unix platforms.
On Fri, 4 Jun 2010, spir wrote:
On Fri, 4 Jun 2010 13:21:09 +0200 (CEST)
Michael Van Canneyt mich...@freepascal.org wrote:
And to be honest, I think we do a very good job of it. Yes, we don't have
100% compatibility. But no, it's never 100%. But it is certainly good
enough to satisfy most
On Fri, 4 Jun 2010, José Mejuto wrote:
Hello FPC-Pascal,
Friday, June 4, 2010, 10:37:42 AM, you wrote:
And this is the backtrace. Any idea ?
JM Maybe you are executing Pascal code in threads that have not been
JM started via the FPC rtl? (i.e., not via beginthread nor via
JM
On 4 June 2010 13:53, Marco van de Voort wrote:
And porting 3rd party delphi code.
I've already ported OS/2 Pascal, C#, Java and C/C++ code to Free
Pascal. It's not that hard at all, so even if FPC is not very Delphi
compatible, porting will still be much easier than porting from other
Op 2010-06-04 14:09, Michael Van Canneyt het geskryf:
Personally, I fail to understand what people are complaining about.
I make my programs with the tools available, and they work damn well.
Michael, the thing is that sometimes somebody will come up with a better
idea for something - yes we
On Fri, 4 Jun 2010, Graeme Geldenhuys wrote:
On 4 June 2010 13:53, Marco van de Voort wrote:
And porting 3rd party delphi code.
I've already ported OS/2 Pascal, C#, Java and C/C++ code to Free
Pascal. It's not that hard at all, so even if FPC is not very Delphi
compatible, porting will
Hello FPC-Pascal,
Friday, June 4, 2010, 2:10:22 PM, you wrote:
If that's the case is any kind of workaround ? Callbacks are only 4 or
5 functions +/- and maybe I can create another thread (in pascal) and
inquiry this thread to process the data and put result in some kind of
shared memory
On 04 Jun 2010, at 14:03, José Mejuto wrote:
Hello FPC-Pascal,
Friday, June 4, 2010, 10:37:42 AM, you wrote:
JM Maybe you are executing Pascal code in threads that have not been
JM started via the FPC rtl? (i.e., not via beginthread nor via
JM tthread.create) That is not supported on Unix
On Fri, 4 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-04 14:09, Michael Van Canneyt het geskryf:
Personally, I fail to understand what people are complaining about.
I make my programs with the tools available, and they work damn well.
Michael, the thing is that sometimes somebody will
Hello Pascaleers,
-1- class wrappers
Are there in stock implementations of class wrappers for primitive types: such
as TInteger, TString, etc? (that would for instance just hold a .value attr and
delegate operations to builtin funcs or procs) This would save me some work :-)
-2- [] operator
On Fri, 4 Jun 2010, spir wrote:
Hello Pascaleers,
-1- class wrappers
Are there in stock implementations of class wrappers for primitive types: such
as TInteger, TString, etc? (that would for instance just hold a .value attr and
delegate operations to builtin funcs or procs) This would
On 04 Jun 2010, at 15:22, Michael Van Canneyt mich...@freepascal.org
wrote:
On Fri, 4 Jun 2010, spir wrote:
-1- class wrappers
Are there in stock implementations of class wrappers for primitive
types: such as TInteger, TString, etc? (that would for instance
just hold a .value attr and
The other problem with Delphi Compatibility is that not even the FPC
team knows which version of Delphi we are supposed to be Delphi
compatible with.
Of course we know: given infinite time, we would support all. Given the
limited time we have, we support the stuff we think being important.
Op 2010-06-04 14:58, Michael Van Canneyt het geskryf:
And as for 'improve quickly':
- Where are the donations ?
- Where are the developers ?
As soon as someone pays me my salary to work full-time on FPC:
there will be REAL quick improvement; I guarantee it.
I have many things I would like
In our previous episode, Graeme Geldenhuys said:
And porting 3rd party delphi code.
I've already ported OS/2 Pascal, C#, Java and C/C++ code to Free
Pascal. It's not that hard at all, so even if FPC is not very Delphi
compatible, porting will still be much easier than porting from other
In our previous episode, Graeme Geldenhuys said:
And if it is just a
hobby to the core developers, why then so damn strict with accepting
improvements (patches, alternative designs etc)?
Hobby doesn't mean we don't care. And it doesn't eliminate a decade (and
longer) experience in
Op 2010-06-04 15:45, Florian Klaempfl het geskryf:
of stuff. Of course, a patch breaking existing stuff will be accepted
less likely.
And yet Embarcadero is ok with breaking compatibility - if it means
improving the product. Yet core developers from FPC and its hobby project
can't get over
In our previous episode, Graeme Geldenhuys said:
Op 2010-06-04 15:45, Florian Klaempfl het geskryf:
of stuff. Of course, a patch breaking existing stuff will be accepted
less likely.
And yet Embarcadero is ok with breaking compatibility - if it means
improving the product. Yet core
On Fri, 4 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-04 14:58, Michael Van Canneyt het geskryf:
And as for 'improve quickly':
- Where are the donations ?
- Where are the developers ?
As soon as someone pays me my salary to work full-time on FPC:
there will be REAL quick improvement; I
spir denis.s...@gmail.com wrote:
I'm surprised of this, fpc still systematically trying to follow
Delphi, after so many years. I can understand that at the beginning
the fpc team needed to mostly comply with Delphi, as de facto object
pascal standard. But then, fpc could live its own life,
Graeme Geldenhuys schrieb:
Op 2010-06-04 15:45, Florian Klaempfl het geskryf:
of stuff. Of course, a patch breaking existing stuff will be accepted
less likely.
And yet Embarcadero is ok with breaking compatibility - if it means
improving the product. Yet core developers from FPC and its
On Fri, 4 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-04 15:45, Florian Klaempfl het geskryf:
of stuff. Of course, a patch breaking existing stuff will be accepted
less likely.
And yet Embarcadero is ok with breaking compatibility - if it means
improving the product.
That is also the
Hello,
This discussion is interesting, but it's a meta-discussion that is
overwhelming this list due to its sheer volume. So let's please move
it to the fpc-other list.
Thanks,
Jonas
FPC mailing lists admin
___
fpc-pascal maillist -
I have a stable cgi program running in windows (no libraries - simple
writeln). However, our web host is in linux. Is there a simple way for
me to cross-compile the app? or is it easier to learn how to use linux
and do it there? I saw a page how to crosscompile lazarus, but it seamed
very
spir wrote:
-2- [] operator
How to implement a class that manages this operator (did not find it
in the operator overloading section). Pointer welcome (including to
the implementation of eg TFPList).
It seems default properties is what you are looking for.
type
TMyClass = class
...
by declaring the property and pressing Ctrl+C
Sorry, I meant Ctrl+Shift+C
--
Regards,
Vladimir Zhirov
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Andreas Berger wrote:
I have a stable cgi program running in windows (no libraries - simple
writeln). However, our web host is in linux. Is there a simple way for
me to cross-compile the app?
I haven't ever cross-compiled anything, but here's a start...
Looking here:
On 4 June 2010 15:19, spir wrote:
-1- class wrappers
Are there in stock implementations of class wrappers for primitive types:
such as TInteger, TString, etc? (that would for instance just hold a .value
attr and delegate operations to builtin funcs or procs) This would save me
some work
On 4 June 2010 17:55, Andreas Berger andr...@thebergerclan.org wrote:
I have a stable cgi program running in windows (no libraries - simple
writeln). However, our web host is in linux. Is there a simple way for me to
cross-compile the app? or is it easier to learn how to use linux and do it
40 matches
Mail list logo
