Op 2010-06-04 08:41, Michael Van Canneyt het geskryf:
>
> It is up to you. Both approaches are possible. Like I said, in the LCL it is
> TWinControl that does the loop over it's child controls. But you could
LCL implements GetChildren in TWinControl, TFrame and TCustomForm. But
looking more clos
On Fri, 4 Jun 2010 00:33:18 +0200
Graeme Geldenhuys 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.
>
> I can't
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 tab
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 hal
On Fri, 04 Jun 2010 08:50:06 +0200
Graeme Geldenhuys 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 understand that at the begin
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 se
On Fri, 4 Jun 2010, spir wrote:
On Fri, 04 Jun 2010 08:50:06 +0200
Graeme Geldenhuys 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.
On Fri, 4 Jun 2010 13:21:09 +0200 (CEST)
Michael Van Canneyt 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, Michael!
No doubt about t
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 com
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 platfo
On Fri, 4 Jun 2010, spir wrote:
On Fri, 4 Jun 2010 13:21:09 +0200 (CEST)
Michael Van Canneyt 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.
H
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> tthread.cre
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
languag
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
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 sti
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 mem
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 co
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
Ho
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 save
On 04 Jun 2010, at 15:22, Michael Van Canneyt
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 delegate operations to
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. If
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 l
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 othe
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 develop
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 cor
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 guar
spir 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, possibly
taking the be
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 "hobb
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 re
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 - fpc-pas
Hello FPC-Pascal,
Friday, June 4, 2010, 2:50:24 PM, you wrote:
>> Not, well, not at least on intention but maybe is the XPCOM which is
>> calling pascal code from a different thread :-? XPCOM tells me across
>> the documentation to call most of its functions from the main thread,
>> but maybe th
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 compl
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:
http://wiki.lazarus.f
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 wor
On 4 June 2010 17:55, 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? or is it easier to learn how to use linux and do it
> there? I saw a page how
41 matches
Mail list logo
