[Lazarus] wiki on a new server
Hi, The Free Pascal and Lazarus wiki has been moved to a new server. Also the wiki software has been upgraded to the latest Mediawiki version. Because porting the custom Free Pascal skin to the new version was too time consuming the default monoskin is used now. Therefore you will notice changes in its appearance. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC/Lazarus wiki pages are not editable any more
Op 23 maart 2012 09:57 heeft Graeme Geldenhuys graemeg.li...@gmail.com het volgende geschreven: It gives the following error: You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in the group: Users. You can view and copy the source of this page: Is this old or new wiki? http://lists.lazarus.freepascal.org/pipermail/lazarus/2012-March/072521.html Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC/Lazarus wiki pages are not editable any more
On 23 March 2012 11:08, Vincent Snijders wrote: Is this old or new wiki? It was both, and rather confusing. In one screen I saw the old, then I saw the new. :-) I guess I was trying to edit as the changeover happened. I also got database locked for maintenance errors. I'll wait a bit, and try again later. If the problem still persists, I'll report back. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
Le 22/03/2012 16:20, Mattias Gaertner a écrit : Each thread has its own stack. All threads share the same address space and the same heap. Objects (here: class instances) are created on the heap. The heap is thread safe. The data segment is for constants. They are shared. Le 22/03/2012 17:10, Michael Schnell a écrit : Besides what the other said a very basic comment. The location where an object is defined (i.e. within a TThread enabled unit) or who created it (the main line code or the thread code) does not matter. The Concept of classes, objects and instances is a matter of memory allocation and pointers and not a concept of program flow. same is absolutely independent. You can use one instance of a class in one thread and another one in another thread. You can create an instance in one thread and call its procedures and properties by another one. (BTW this results in the fact that its very hard to define something like Thread-safe for a class). Thanks to you all . Trying to be as much clear as possible, there are some sentences: Assuming this few statements (aka my own rules when writing thread's code): a. all thread code+data are encapsulated into a TThread object b. Thread safe means that there is no overlap of data references from thread to thread, the main thread inclusive, and that no references are passed outside the thread's control from thread to thread (by the means of the owner or global vars for instance) c. the thread creator does not interfere in any way with the thread's data and methods as soon as the thread has been started (Terminated execpted of course) d. no function neither procedure calls are made to any function or procedure defined outside of the thread control (aka self defined methods) Do you all agree on the following asserts: 1. All variables in the thread definition (TThread's private, protected and public variables) are Thread safe BUT are accessible to the thread creator 2. an instance of an object (aka TObject descendant) created into the thread's EXECUTE procedure is invisible to all other instances of the same object whichever the creator could be (the same thread or other threads created with the same thread definition object) and to other thread object instances, even when the reference variable of the created object is defined into the thread vars (see 1.) provided that all object methods do not call any function or procedure outside of the object methods. 3. all variables described in the VAR part of the EXECUTE procedure are Thread safe (seems obvious) 4. all local variables and constants defined into local Thread object methods are Thread safe (they are defined into each thread stack for the vars and the heap for constants) 5. all useful code a thread needs should be encapsultated into a TObject descendant and instantiated within the thread's space. 6. all methods defined in the thread's definition, aprat from the EXECUTE procedure (obvious !), run into the thread creator space (the one which instantiates the thread, aka does something like wThread := TMyThread.Create (False) ) This list is (certainly) not exhausted. Antonio. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
Am 23.03.2012 10:25, schrieb Antonio Fortuny:
Le 22/03/2012 16:20, Mattias Gaertner a écrit :
Each thread has its own stack.
All threads share the same address space and the same heap.
Objects (here: class instances) are created on the heap. The heap is
thread safe.
The data segment is for constants. They are shared.
Le 22/03/2012 17:10, Michael Schnell a écrit :
Besides what the other said a very basic comment.
The location where an object is defined (i.e. within a TThread enabled
unit) or who created it (the main line code or the thread code) does
not matter. The Concept of classes, objects and instances is a matter
of memory allocation and pointers and not a concept of program flow.
same is absolutely independent. You can use one instance of a class in
one thread and another one in another thread. You can create an
instance in one thread and call its procedures and properties by
another one. (BTW this results in the fact that its very hard to
define something like Thread-safe for a class).
Thanks to you all .
Trying to be as much clear as possible, there are some sentences:
Assuming this few statements (aka my own rules when writing thread's code):
a. all thread code+data are encapsulated into a TThread object
b. Thread safe means that there is no overlap of data references from
thread to thread, the main thread inclusive, and that no references are
passed outside the thread's control from thread to thread (by the means
of the owner or global vars for instance)
c. the thread creator does not interfere in any way with the thread's
data and methods as soon as the thread has been started (Terminated
execpted of course)
d. no function neither procedure calls are made to any function or
procedure defined outside of the thread control (aka self defined methods)
Ok, I hereby assume the above as given.
Do you all agree on the following asserts:
1. All variables in the thread definition (TThread's private, protected
and public variables) are Thread safe BUT are accessible to the thread
creator
Yes (though the private vars aren't available to the thread creator if
the creator and the definition of your TThread descendant reside in
different units ;) )
2. an instance of an object (aka TObject descendant) created into the
thread's EXECUTE procedure is invisible to all other instances of the
same object whichever the creator could be (the same thread or other
threads created with the same thread definition object) and to other
thread object instances, even when the reference variable of the created
object is defined into the thread vars (see 1.) provided that all object
methods do not call any function or procedure outside of the object methods.
If I've understood that correctly: yes
3. all variables described in the VAR part of the EXECUTE procedure are
Thread safe (seems obvious)
Yes
4. all local variables and constants defined into local Thread object
methods are Thread safe (they are defined into each thread stack for
the vars and the heap for constants)
It's true for variables. Local constants are defined in a section of the
executable, so if you have writable constants enabled (only then it's a
problem) and you write to these constants then the change will be
reflected in other constants as well. If you don't write to the
constants than they are safe.
5. all useful code a thread needs should be encapsultated into a TObject
descendant and instantiated within the thread's space.
Note necessarily. You can also call global procedures/functions that
don't rely on global state (e.g. IntToStr, etc.). If you want to call
functions/procedures that rely on the state (e.g. some registration
systems for classes) you'll need to synchronize the access.
6. all methods defined in the thread's definition, aprat from the
EXECUTE procedure (obvious !), run into the thread creator space (the
one which instantiates the thread, aka does something like wThread :=
TMyThread.Create (False) )
I don't know whether I understood you correctly, but if you have this:
=== example begin ===
type
TTestThread = class(TThread)
protected
procedure Execute; override;
public
procedure DoSomething;
end;
procedure TTestThread.Execute;
begin
DoSomething;
end;
procedure TTestThread.DoSomething;
begin
Writeln('Something');
end;
begin
with TTestThread.Create(True) do begin
FreeOnTerminate := True;
Start;
end;
end.
=== example end ===
Then (to my understandment of your assertion) your assertion is wrong,
because DoSomething is (although it is public) only called in context of
Execute (Note: Not that you should make such a method public if you
don't need to, but this is merely an example).
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
Antonio Fortuny schrieb: Trying to be as much clear as possible, there are some sentences: Assuming this few statements (aka my own rules when writing thread's code): a. all thread code+data are encapsulated into a TThread object b. Thread safe means that there is no overlap of data references from thread to thread, the main thread inclusive, and that no references are passed outside the thread's control from thread to thread (by the means of the owner or global vars for instance) c. the thread creator does not interfere in any way with the thread's data and methods as soon as the thread has been started (Terminated execpted of course) d. no function neither procedure calls are made to any function or procedure defined outside of the thread control (aka self defined methods) Looks good :-) Do you all agree on the following asserts: 1. All variables in the thread definition (TThread's private, protected and public variables) are Thread safe BUT are accessible to the thread creator The OPL visibility rules apply. Public members are accessible by everybody, others only from inside the unit where the thread class is declared. As long as the thread creator doesn't export the thread object, nobody else can access it, of course. 5. all useful code a thread needs should be encapsultated into a TObject descendant and instantiated within the thread's space. This can all be implemented in the derived TThread class. 6. all methods defined in the thread's definition, aprat from the EXECUTE procedure (obvious !), run into the thread creator space (the one which instantiates the thread, aka does something like wThread := TMyThread.Create (False) ) Every procedure or method runs in the context of its *caller*. Everything called from the thread's Execute method executes in the thread context (stack, threadvars). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Size of binaries etc.
Mattias Gaertner wrote: On Thu, 22 Mar 2012 18:31:06 + Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote: Felipe Monteiro de Carvalho wrote: I did some tests here and I guess this is simply the normal size of an app if you use ComCtrls. 1,5MB was for a minimal app with a form and some buttons. ComCtrls alone adds 1MB You can check this in the menu Project-Show used ppu files (might be 0.9.31+ only). You've hit it on the head. Cody shows that ComCtrls is being pulled in as part of LCLBase, even if none of its controls are being used (in the current case, the test form and associated unit are entirely empty). Shouldn't at least some of this be excluded by smartlinking? Cody values are before smart linking. I heard there is a compiler flag that shows information after smart linking. If anybody has any thoughts as to how to enable this I'd be interested to know. Otherwise I'll just have to live with the issue, noting that in general it's a one-time overhead. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Size of binaries etc.
Hello, This is clearly something from UNIXes. I just tested using LCL-Win32 and a minimal app with 1 form and 1 button has 1,62MB In Mac OS X my result was 2,8MB I suspect that the smartlinking is less efficient in UNIXes. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
Thanks Sven, I really appreciate.
Le 23/03/2012 10:59, Sven Barth a écrit :
Am 23.03.2012 10:25, schrieb Antonio Fortuny:
Le 22/03/2012 16:20, Mattias Gaertner a écrit :
Each thread has its own stack.
All threads share the same address space and the same heap.
Objects (here: class instances) are created on the heap. The heap is
thread safe.
The data segment is for constants. They are shared.
Le 22/03/2012 17:10, Michael Schnell a écrit :
Besides what the other said a very basic comment.
The location where an object is defined (i.e. within a TThread enabled
unit) or who created it (the main line code or the thread code) does
not matter. The Concept of classes, objects and instances is a matter
of memory allocation and pointers and not a concept of program flow.
same is absolutely independent. You can use one instance of a class in
one thread and another one in another thread. You can create an
instance in one thread and call its procedures and properties by
another one. (BTW this results in the fact that its very hard to
define something like Thread-safe for a class).
Thanks to you all .
Trying to be as much clear as possible, there are some sentences:
Assuming this few statements (aka my own rules when writing thread's
code):
a. all thread code+data are encapsulated into a TThread object
b. Thread safe means that there is no overlap of data references from
thread to thread, the main thread inclusive, and that no references are
passed outside the thread's control from thread to thread (by the means
of the owner or global vars for instance)
c. the thread creator does not interfere in any way with the thread's
data and methods as soon as the thread has been started (Terminated
execpted of course)
d. no function neither procedure calls are made to any function or
procedure defined outside of the thread control (aka self defined
methods)
Ok, I hereby assume the above as given.
Do you all agree on the following asserts:
1. All variables in the thread definition (TThread's private, protected
and public variables) are Thread safe BUT are accessible to the thread
creator
Yes (though the private vars aren't available to the thread creator if
the creator and the definition of your TThread descendant reside in
different units ;) )
2. an instance of an object (aka TObject descendant) created into the
thread's EXECUTE procedure is invisible to all other instances of the
same object whichever the creator could be (the same thread or other
threads created with the same thread definition object) and to other
thread object instances, even when the reference variable of the created
object is defined into the thread vars (see 1.) provided that all object
methods do not call any function or procedure outside of the object
methods.
If I've understood that correctly: yes
3. all variables described in the VAR part of the EXECUTE procedure are
Thread safe (seems obvious)
Yes
4. all local variables and constants defined into local Thread object
methods are Thread safe (they are defined into each thread stack for
the vars and the heap for constants)
It's true for variables. Local constants are defined in a section of
the executable, so if you have writable constants enabled (only then
it's a problem) and you write to these constants then the change will
be reflected in other constants as well. If you don't write to the
constants than they are safe.
Well, when I define a *const* anywhere in a program it is a *constant*
actually otherwise I use a var. In this case I guess than there is no
problem for any thread to read a constant whatever the context could be
5. all useful code a thread needs should be encapsultated into a TObject
descendant and instantiated within the thread's space.
Note necessarily. You can also call global procedures/functions that
don't rely on global state (e.g. IntToStr, etc.). If you want to call
functions/procedures that rely on the state (e.g. some registration
systems for classes) you'll need to synchronize the access.
Is it more accurate to state that any global procedure or function could
be called by any thread as far as the called code does not reference
anything outside itself apart from other global code considered as
Tread safe too or constants. For example StrToIntDef.
6. all methods defined in the thread's definition, aprat from the
EXECUTE procedure (obvious !), run into the thread creator space (the
one which instantiates the thread, aka does something like wThread :=
TMyThread.Create (False) )
I don't know whether I understood you correctly, but if you have this:
=== example begin ===
type
TTestThread = class(TThread)
protected
procedure Execute; override;
public
procedure DoSomething;
end;
procedure TTestThread.Execute;
begin
DoSomething;
end;
procedure TTestThread.DoSomething;
begin
Writeln('Something');
end;
begin
with TTestThread.Create(True) do begin
FreeOnTerminate := True;
Start;
end;
end.
Re: [Lazarus] Size of binaries etc.
Am 23.03.2012 11:10, schrieb Felipe Monteiro de Carvalho: Hello, This is clearly something from UNIXes. I just tested using LCL-Win32 and a minimal app with 1 form and 1 button has 1,62MB In Mac OS X my result was 2,8MB I suspect that the smartlinking is less efficient in UNIXes. Might be because of the internal linker on Windows platforms. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] RE : Size of binaries etc.
Cody values are before smart linking. I heard there is a compiler flag that shows information after smart linking. If anybody has any thoughts as to how to enable this I'd be interested to know. Otherwise I'll just have to live with the issue, noting that in general it's a one-time overhead. Adding -Xm to the compiler options will create a link map. This contains a long list of what references what and the functions kept or removed by the linker. Ludo -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
Many thanks Dodi. Antonio. Le 23/03/2012 10:59, Hans-Peter Diettrich a écrit : Antonio Fortuny schrieb: Trying to be as much clear as possible, there are some sentences: Assuming this few statements (aka my own rules when writing thread's code): a. all thread code+data are encapsulated into a TThread object b. Thread safe means that there is no overlap of data references from thread to thread, the main thread inclusive, and that no references are passed outside the thread's control from thread to thread (by the means of the owner or global vars for instance) c. the thread creator does not interfere in any way with the thread's data and methods as soon as the thread has been started (Terminated execpted of course) d. no function neither procedure calls are made to any function or procedure defined outside of the thread control (aka self defined methods) Looks good :-) Do you all agree on the following asserts: 1. All variables in the thread definition (TThread's private, protected and public variables) are Thread safe BUT are accessible to the thread creator The OPL visibility rules apply. Public members are accessible by everybody, others only from inside the unit where the thread class is declared. As long as the thread creator doesn't export the thread object, nobody else can access it, of course. I agree with you that the assertion could be more precise when talking about object members visibility. But we are talking abount OOP, aren't we ? 8-) 5. all useful code a thread needs should be encapsultated into a TObject descendant and instantiated within the thread's space. This can all be implemented in the derived TThread class. So, building an object around this utility code does not enlarge thread safety ? 6. all methods defined in the thread's definition, aprat from the EXECUTE procedure (obvious !), run into the thread creator space (the one which instantiates the thread, aka does something like wThread := TMyThread.Create (False) ) Every procedure or method runs in the context of its *caller*. Everything called from the thread's Execute method executes in the thread context (stack, threadvars). Sounds very clear. Big idea using few words. I appeciate. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Size of binaries etc.
On Thu, Mar 22, 2012 at 12:22:12AM -0400, waldo kitty wrote: are also others that were used between bbs door games/apps and the terminal... globalwar was one of those games and tradewars also had one ;) Tradewars originally was a Turbo Pascal app (for very old WWIV versions, source is available iirc), afaik later redone in some C++ dialect (watcom?) when they moved to Martech. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Size of binaries etc.
On Fri, Mar 23, 2012 at 11:10:46AM +0100, Felipe Monteiro de Carvalho wrote: This is clearly something from UNIXes. I just tested using LCL-Win32 and a minimal app with 1 form and 1 button has 1,62MB In Mac OS X my result was 2,8MB I suspect that the smartlinking is less efficient in UNIXes. OS X has a different binary format and assembler/linker from *BSD and Linux, so OS X in this way is as different from them as Windows is. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
Am 23.03.2012 14:11, schrieb Frank Church: Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected? Of late when I look the definition of a form, it all seems so odd to me that properties, objects etc which are not meant to be accessible to external modules are automatically visible. I just want to check on how the form or module fits into the overall program just by looking at the public and published properties. Am I missing something about the ideas about Delphi and Lazarus which are supposed to be obvious? All objects that should be placed in the lfm/dfm file MUST be placed in the published section in Delphi and Lazarus, because they are only streamed if there is RTTI for them for which published was created. Yes, there are other approaches, e.g. fpGUI has an IDE that has the GUI creation in code and of which the IDE parses and modifies the initialization routine to display a designer form, and another possiblity would be - if they'd be implemented in FPC - the extended RTTI which allows you to specify that also e.g. private fields have RTTI generated and (with an adjusted streaming system) this could also be used. But neither Delphi nor Lazarus uses this approach, so you must live with that (for now). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
On 23 March 2012 13:28, michael.vancann...@wisa.be wrote: On Fri, 23 Mar 2012, Frank Church wrote: Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected? Which properties and events ? Can you give an example ? Of late when I look the definition of a form, it all seems so odd to me that properties, objects etc which are not meant to be accessible to external modules are automatically visible. Such as ? And visible where ? In the code tools, or in the Object Inspector ? Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus I am referring more to the source code itself. After adding lots of forms, data modules etc, I look at a datamodule or a form (more relevant with datamodules) and ask myself What does this module do? and find myself staring at procedure after procedure in a bit of confusion. I'd prefer to look only at the public section and say, Oh, this is what it does for the program's other modules. Whatever isn't there is not relevant to the rest of the application. I understand that it comes from a Delphi legacy as RAD tool dating from a time when the principles underlying object orientation had not properly sunk in. It makes me wonder whether I've got my whole approach to object orientation and encapsulation with Object Pascal wrong or misconceived as a result of that. I guess it is more obvious if you start using Lazarus of FPC more on the non visual areas. -- Frank Church === http://devblog.brahmancreations.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
Am 23.03.2012 14:55, schrieb Frank Church: [...] I'd prefer to look only at the public section and say, Oh, this is what it does for the program's other modules. Whatever isn't there is not relevant to the rest of the application. I understand that it comes from a Delphi legacy as RAD tool dating from a time when the principles underlying object orientation had not properly sunk in. [...] You can already do this by changing the way you are programming. Just write a class which only publish the needed methods and properties to the outside. Don't let the Application create and control your forms, move this to your class. So, your class hides the forms, datampdules and other stuff. hth Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
On 23 March 2012 13:49, Sven Barth pascaldra...@googlemail.com wrote: Am 23.03.2012 14:11, schrieb Frank Church: Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected? Of late when I look the definition of a form, it all seems so odd to me that properties, objects etc which are not meant to be accessible to external modules are automatically visible. I just want to check on how the form or module fits into the overall program just by looking at the public and published properties. Am I missing something about the ideas about Delphi and Lazarus which are supposed to be obvious? All objects that should be placed in the lfm/dfm file MUST be placed in the published section in Delphi and Lazarus, because they are only streamed if there is RTTI for them for which published was created. Yes, there are other approaches, e.g. fpGUI has an IDE that has the GUI creation in code and of which the IDE parses and modifies the initialization routine to display a designer form, and another possiblity would be - if they'd be implemented in FPC - the extended RTTI which allows you to specify that also e.g. private fields have RTTI generated and (with an adjusted streaming system) this could also be used. But neither Delphi nor Lazarus uses this approach, so you must live with that (for now). I remember this aspect form asking a similar question some time back. What of the event handlers, is it the nature of the form designer which requires them to be visible as well? It is possible also to set an eventhandler to a routine in other file, but ideally shouldn't that be something the develop can choose to expose only when he requires it? I am now considering placeing an intermediate classes between the consumers and producers in order to hide those details, so that instead of some form calling a data module directly, it calls an intermediate class that accesses the data module through the methods and properties of that class.. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- Frank Church === http://devblog.brahmancreations.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
On 23 March 2012 14:02, Michael Fuchs freepas...@ypa-software.de wrote: Am 23.03.2012 14:55, schrieb Frank Church: [...] I'd prefer to look only at the public section and say, Oh, this is what it does for the program's other modules. Whatever isn't there is not relevant to the rest of the application. I understand that it comes from a Delphi legacy as RAD tool dating from a time when the principles underlying object orientation had not properly sunk in. [...] You can already do this by changing the way you are programming. Just write a class which only publish the needed methods and properties to the outside. Don't let the Application create and control your forms, move this to your class. So, your class hides the forms, datampdules and other stuff. This is what I have been considering. hth Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- Frank Church === http://devblog.brahmancreations.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
On Fri, 23 Mar 2012, Michael Fuchs wrote: Am 23.03.2012 14:55, schrieb Frank Church: [...] I'd prefer to look only at the public section and say, Oh, this is what it does for the program's other modules. Whatever isn't there is not relevant to the rest of the application. I understand that it comes from a Delphi legacy as RAD tool dating from a time when the principles underlying object orientation had not properly sunk in. [...] You can already do this by changing the way you are programming. Just write a class which only publish the needed methods and properties to the outside. Don't let the Application create and control your forms, move this to your class. So, your class hides the forms, datampdules and other stuff. That's what I do too. unit appforms; type TBaseMyForm = Class(TForm) // Define public interface end; TBaseMyFormClass = Class of TBaseMyForm; Var MyFormClass : TBaseMyFormClass = Nil And then somewhere: Type TForm = TBaseMyForm; TMyForm = Class(TForm); // Regular lazarus definition of form end; initialization MyFormClass = TMyForm; end; And then, whenever I need an instance of TBaseMyForm: F:=MyFormClass.Create(Self); You could even substitute the complete TMyForm form with another one, depending on configuration options. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it possible to drag and drop a web browser URL into a Lazarus app?
2012/3/22 Graeme Geldenhuys graemeg.li...@gmail.com: On 20 March 2012 16:37, Frank Church vfclists@... wrote: Is it possible to drag and drop a web browser URL into a Lazarus app? Are there some controls with that facility? In fpGUI is is handled just like any other DND action. Simply register what mime-type the drop target must look out for. It will then happile accept a drop action if such a mime-type is supplied. Simple and easy to use, and works on all platforms. Lazarus's drag-n-drop is based on the very limited Delphi / Windows DND, so is mainly build for in-app drag-n-drop, and not able to accept external drag-n-drop actions. Normally (in Delphi) you would have to revert to Windows API calls to get better DND support. I remember seeing them (the Lazarus team) extending the default limited DND a bit to support dropping files on a LCL app, but that is a far cry from complete DND support. Out of interest, I ran the DND Demo of fpGUI, which shows what mime-types the source of a DND action is willing to supply. I dragged the URL from the Chrome web browser and dropped in onto the Text Edit field. Below that is the complete list of mime-types (8 in total) that Chrome was willing to supply the data in. I don't know if this information will help you with your LCL application in any way. fpGUI is something I should be trying out more. I have remember that Lazarus doesn't always mean LCL :) Your example fits my need perfectly. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- Frank Church === http://devblog.brahmancreations.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
It's rather straight forward to do completely distinct threads. The tricky part starts, when the threads need to communicate (which always is necessary) and thus share some data. Here you need to be aware of several things: - the components and functions in the LCL and RTL usually are not thread-save (and there is no documentation on in what way they are partly thread safe) e.g. - - Many simple functions like IntToStr() seem to thread safe, but this is not documented. - - You can't use any function that accesses the GUI in another thread but the main thread. - - You can happily use multiple instances of TList in multiple threads as long as each a single instance is not used by multiple threads. - - You can use the same instance of TList in multiple threads if you use a TCtriticalSection (e.g. one for each instance of TList) do block concurrent accesses. - - AFAIK, the way TThreadList is used with multiple threads is documented. - To have a worker thread communicate with the main thread (i.e. to have it use the GUI in any way) you can use TThread.Synchronize. Downside: The thread waits until any scheduled main thread activity is done before entering the synchronized code (might last forever). It only goes on working when the synchronized code is done. - To trigger a main thread activity without having to wait for the main thread you can use Application.QueueAsnycCall. - The functionality of TThread.Synchronize and Application.QueuAsyncCall is not available in all Widget Types (see Compile-Options - Build Modes). It is verified to work decently in GTK and Win32 (and supposedly QT, but I did not check this myself). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
Am 23.03.2012 15:13, schrieb Frank Church: On 23 March 2012 13:49, Sven Barthpascaldra...@googlemail.com wrote: Am 23.03.2012 14:11, schrieb Frank Church: Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected? Of late when I look the definition of a form, it all seems so odd to me that properties, objects etc which are not meant to be accessible to external modules are automatically visible. I just want to check on how the form or module fits into the overall program just by looking at the public and published properties. Am I missing something about the ideas about Delphi and Lazarus which are supposed to be obvious? All objects that should be placed in the lfm/dfm file MUST be placed in the published section in Delphi and Lazarus, because they are only streamed if there is RTTI for them for which published was created. Yes, there are other approaches, e.g. fpGUI has an IDE that has the GUI creation in code and of which the IDE parses and modifies the initialization routine to display a designer form, and another possiblity would be - if they'd be implemented in FPC - the extended RTTI which allows you to specify that also e.g. private fields have RTTI generated and (with an adjusted streaming system) this could also be used. But neither Delphi nor Lazarus uses this approach, so you must live with that (for now). I remember this aspect form asking a similar question some time back. What of the event handlers, is it the nature of the form designer which requires them to be visible as well? It is possible also to set an eventhandler to a routine in other file, but ideally shouldn't that be something the develop can choose to expose only when he requires it? If you want to set event handlers through the object inspector, then you need to have them published as well, because only then MethodAddress which is used in the streaming will return something besides Nil. I am now considering placeing an intermediate classes between the consumers and producers in order to hide those details, so that instead of some form calling a data module directly, it calls an intermediate class that accesses the data module through the methods and properties of that class.. This is maybe one of the better approaches you can do. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
On 23 March 2012 14:15, michael.vancann...@wisa.be wrote: On Fri, 23 Mar 2012, Michael Fuchs wrote: Am 23.03.2012 14:55, schrieb Frank Church: [...] I'd prefer to look only at the public section and say, Oh, this is what it does for the program's other modules. Whatever isn't there is not relevant to the rest of the application. I understand that it comes from a Delphi legacy as RAD tool dating from a time when the principles underlying object orientation had not properly sunk in. [...] You can already do this by changing the way you are programming. Just write a class which only publish the needed methods and properties to the outside. Don't let the Application create and control your forms, move this to your class. So, your class hides the forms, datampdules and other stuff. That's what I do too. unit appforms; type TBaseMyForm = Class(TForm) // Define public interface end; TBaseMyFormClass = Class of TBaseMyForm; Var MyFormClass : TBaseMyFormClass = Nil And then somewhere: Type TForm = TBaseMyForm; TMyForm = Class(TForm); // Regular lazarus definition of form end; initialization MyFormClass = TMyForm; end; And then, whenever I need an instance of TBaseMyForm: F:=MyFormClass.Create(Self); You could even substitute the complete TMyForm form with another one, depending on configuration options. Michael. Do you have a good working sample of this approach? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- Frank Church === http://devblog.brahmancreations.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
Le 23/03/2012 15:24, Michael Schnell a écrit : It's rather straight forward to do completely distinct threads. The tricky part starts, when the threads need to communicate (which always is necessary) and thus share some data. Here you need to be aware of several things: - the components and functions in the LCL and RTL usually are not thread-save (and there is no documentation on in what way they are partly thread safe) e.g. - - Many simple functions like IntToStr() seem to thread safe, but this is not documented. - - You can't use any function that accesses the GUI in another thread but the main thread. - - You can happily use multiple instances of TList in multiple threads as long as each a single instance is not used by multiple threads. - - You can use the same instance of TList in multiple threads if you use a TCtriticalSection (e.g. one for each instance of TList) do block concurrent accesses. - - AFAIK, the way TThreadList is used with multiple threads is documented. - To have a worker thread communicate with the main thread (i.e. to have it use the GUI in any way) you can use TThread.Synchronize. Downside: The thread waits until any scheduled main thread activity is done before entering the synchronized code (might last forever). It only goes on working when the synchronized code is done. - To trigger a main thread activity without having to wait for the main thread you can use Application.QueueAsnycCall. - The functionality of TThread.Synchronize and Application.QueuAsyncCall is not available in all Widget Types (see Compile-Options - Build Modes). It is verified to work decently in GTK and Win32 (and supposedly QT, but I did not check this myself). All those are the basics that I apply since I'm busy writing threads code. I already make use of Critical sections and events lock some external resources (log files for instance) and I avoid to have any thread code using any kind of GUI. All thread code I write, is contained in OS services or very specialized programs having no GUI at all. Anyway, thanks for precisions. Antonio. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
On Fri, 23 Mar 2012, Frank Church wrote: On 23 March 2012 14:15, michael.vancann...@wisa.be wrote: On Fri, 23 Mar 2012, Michael Fuchs wrote: Am 23.03.2012 14:55, schrieb Frank Church: [...] I'd prefer to look only at the public section and say, Oh, this is what it does for the program's other modules. Whatever isn't there is not relevant to the rest of the application. I understand that it comes from a Delphi legacy as RAD tool dating from a time when the principles underlying object orientation had not properly sunk in. [...] You can already do this by changing the way you are programming. Just write a class which only publish the needed methods and properties to the outside. Don't let the Application create and control your forms, move this to your class. So, your class hides the forms, datampdules and other stuff. That's what I do too. unit appforms; type TBaseMyForm = Class(TForm) // Define public interface end; TBaseMyFormClass = Class of TBaseMyForm; Var MyFormClass : TBaseMyFormClass = Nil And then somewhere: Type TForm = TBaseMyForm; TMyForm = Class(TForm); // Regular lazarus definition of form end; initialization MyFormClass = TMyForm; end; And then, whenever I need an instance of TBaseMyForm: F:=MyFormClass.Create(Self); You could even substitute the complete TMyForm form with another one, depending on configuration options. Michael. Do you have a good working sample of this approach? Yes, all my apps at work. But they are not open source :/ It's really not much more than what I wrote above. Just one large unit with a lot of 'base form' definitions and class pointers for each of them. Michael.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
Am 23.03.2012 15:36, schrieb Antonio Fortuny: Le 23/03/2012 15:24, Michael Schnell a écrit : It's rather straight forward to do completely distinct threads. The tricky part starts, when the threads need to communicate (which always is necessary) and thus share some data. Here you need to be aware of several things: - the components and functions in the LCL and RTL usually are not thread-save (and there is no documentation on in what way they are partly thread safe) e.g. - - Many simple functions like IntToStr() seem to thread safe, but this is not documented. - - You can't use any function that accesses the GUI in another thread but the main thread. - - You can happily use multiple instances of TList in multiple threads as long as each a single instance is not used by multiple threads. - - You can use the same instance of TList in multiple threads if you use a TCtriticalSection (e.g. one for each instance of TList) do block concurrent accesses. - - AFAIK, the way TThreadList is used with multiple threads is documented. - To have a worker thread communicate with the main thread (i.e. to have it use the GUI in any way) you can use TThread.Synchronize. Downside: The thread waits until any scheduled main thread activity is done before entering the synchronized code (might last forever). It only goes on working when the synchronized code is done. - To trigger a main thread activity without having to wait for the main thread you can use Application.QueueAsnycCall. - The functionality of TThread.Synchronize and Application.QueuAsyncCall is not available in all Widget Types (see Compile-Options - Build Modes). It is verified to work decently in GTK and Win32 (and supposedly QT, but I did not check this myself). All those are the basics that I apply since I'm busy writing threads code. I already make use of Critical sections and events lock some external resources (log files for instance) and I avoid to have any thread code using any kind of GUI. All thread code I write, is contained in OS services or very specialized programs having no GUI at all. Anyway, thanks for precisions. Just for the case you understood that wrong: There is no pricincipal problem of threads running in a GUI app. The problems arise only if you access some visual component (e.g. change the Caption of a Label) without using Synchronize. If you either use Synchronize or your threads don't access the GUI directly, then you won't have problems with them. E.g. the scanning of the Free Pascal source directory at the first start of Lazarus (or when you change the source directory) is done using a thread. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it possible to drag and drop a web browser URL into a Lazarus app?
On Thu, Mar 22, 2012 at 2:14 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Feel free to file an feature request. A patch would be much more useful. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
All those are the basics that I apply since I'm busy writing threads code. I already make use of Critical sections and events lock some external resources (log files for instance) and I avoid to have any thread code using any kind of GUI. All thread code I write, is contained in OS services or very specialized programs having no GUI at all. Anyway, thanks for precisions. Just for the case you understood that wrong: There is no pricincipal problem of threads running in a GUI app. The problems arise only if you access some visual component (e.g. change the Caption of a Label) without using Synchronize. If you either use Synchronize or your threads don't access the GUI directly, then you won't have problems with them. Ok, sorry, confusing sentence. I mean that I'm aware of Synchronize use (thanks to multiple crashes ;-) ) and interfacing threads with other threads or processes (I use a shared Q of my own with, of course, critical section, signals and events, etc to be as much independent of OS as possible but this is another point) and I use them sometimes when I write some thread code in a GUI application. No problem with that. In my mind I was thinking on services which do not have (but can have) a GUI. Again, I think it is useful to be as precise and accurate as possible on this matters. Thanks Sven. E.g. the scanning of the Free Pascal source directory at the first start of Lazarus (or when you change the source directory) is done using a thread. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
On 03/23/2012 03:36 PM, Antonio Fortuny wrote: All thread code I write, is contained in OS services or very specialized programs having no GUI at all. Here this issue might be a problem (it was for me): - The functionality of TThread.Synchronize and Application.QueuAsyncCall is not available in all Widget Types (see Compile-Options - Build Modes). It is verified to work decently in GTK and Win32 (and supposedly QT, but I did not check this myself). Using any of the non standard PC GUI aware Lazarus Widget types, you can't have a main thread and thus not event driven programming and thus no events that are scheduled by threads. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
BTW.: Do you know this ? www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf -Michael O:-) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?
Frank Church schrieb: Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected? Then derive from TCustomForm instead of TForm. As for most TCustom... classes, TCustomForm declares all essential properties as protected, and only TForm publishes those properties, which shall be editable at design time (in the OI). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads
Antonio Fortuny schrieb: 5. all useful code a thread needs should be encapsultated into a TObject descendant and instantiated within the thread's space. This can all be implemented in the derived TThread class. So, building an object around this utility code does not enlarge thread safety ? Not really. Thread safe code must not access global variables, neither directly nor indirectly in called subroutines. The latter cannot be assured by wrapping the code in a class. See also: 6. all methods defined in the thread's definition, aprat from the EXECUTE procedure (obvious !), run into the thread creator space (the one which instantiates the thread, aka does something like wThread := TMyThread.Create (False) ) Every procedure or method runs in the context of its *caller*. Everything called from the thread's Execute method executes in the thread context (stack, threadvars). Sounds very clear. Big idea using few words. I appeciate. :-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] ETL tool - make or use?
Der list members, does anyone of you know a tool for ETL[1] tasks? At best it would be written in object pascal and be open source. I'm currently charged with doing some simple data transfer actions like loading CSV (aka SDF) data and pushing those records to a relational database and the like. I have the strong feeling that someone has already done something like that. ;) Options to solve this request are 1. whipping together minimal code that does it 2. make a more generic tool that can be used for all tasks, having to be extended when needed 3. use some tool already existing Some tools I tried or looked at are mostly written in Java and do suck ressources, or they are not able to handle some requirements (like databases in use) or are closed source. Last tests were done using OpenAdaptor[2] which is really cool but has problems with posgresql and demands being familiar with spring. There is still Pentaho Data Integration[3] n the list of tools to do some testing with. What do you use for ETL tasks? TIA, Marc [1] http://en.wikipedia.org/wiki/Extract,_transform,_load [2] https://www.openadaptor.org/ [3] http://www.pentaho.com/explore/pentaho-data-integration/ -- Marc Santhoff m.santh...@web.de -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ETL tool - make or use?
On Fri, 23 Mar 2012, Marc Santhoff wrote: Der list members, does anyone of you know a tool for ETL[1] tasks? At best it would be written in object pascal and be open source. I'm currently charged with doing some simple data transfer actions like loading CSV (aka SDF) data and pushing those records to a relational database and the like. I have the strong feeling that someone has already done something like that. ;) Options to solve this request are 1. whipping together minimal code that does it 2. make a more generic tool that can be used for all tasks, having to be extended when needed 3. use some tool already existing Some tools I tried or looked at are mostly written in Java and do suck ressources, or they are not able to handle some requirements (like databases in use) or are closed source. Last tests were done using OpenAdaptor[2] which is really cool but has problems with posgresql and demands being familiar with spring. There is still Pentaho Data Integration[3] n the list of tools to do some testing with. What do you use for ETL tasks? Always option 1. Because it always turns out you need to check for doubles and do updates; making self written code the most optimal tool. You always know your own data best of all. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ETL tool - make or use?
Marc Santhoff wrote: Der list members, does anyone of you know a tool for ETL[1] tasks? At best it would be written in object pascal and be open source. I'm currently charged with doing some simple data transfer actions like loading CSV (aka SDF) data and pushing those records to a relational database and the like. I have the strong feeling that someone has already done something like that. ;) Options to solve this request are 1. whipping together minimal code that does it 2. make a more generic tool that can be used for all tasks, having to be extended when needed 3. use some tool already existing Some tools I tried or looked at are mostly written in Java and do suck ressources, or they are not able to handle some requirements (like databases in use) or are closed source. Last tests were done using OpenAdaptor[2] which is really cool but has problems with posgresql and demands being familiar with spring. There is still Pentaho Data Integration[3] n the list of tools to do some testing with. What do you use for ETL tasks? I'm a heretic: I tend to use Perl. I notice that somebody's embedded Perl in Delphi- I wonder if that would be portable to FPC? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Size of binaries etc.
2012/3/21 Mark Morgan Lloyd markmll.laza...@telemetry.co.uk: On Linux x86 (Debian Squeeze) with gtk2, freshly-created minimal project with full optimisation, no debug, optimise for minimum size and smart linking comes to 3,459,960 bytes. That's... such a disparity from what I've been told to expect that I'd appreciate any suggestions as to where I should be looking for problems. You must be doing something wrong. On i386-linux/GTK2 with everything smart-linkable and smart-linked and stripped I get 2MB (2113600 bytes) for a minimal application with only one button and one label. (everything compiled with -g- -O3 -CX -XX -Xs) With upx the 2MB go down to 700kB, without smart-linking I get around 4MB. Make sure while you are compiling your project in Lazarus you also have -CX in the options of the build lazarus Dialog because otherwise when compiling your project it will automatically (re-)compile the LCL without smartlinking. It will always recompile (if necessary) the LCL and all dependent units with the settings that are currently active for build lazarus whenever you compile a project. (I discovered this by accident but it is quite useful: I always thought I had to explicitly recompile the entire Lazarus after changing these options but it is enough to just change the options and then only recompile your project) Bernd -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
