On Fri, Aug 14, 2009 at 02:58:34PM +0200, Michael Van Canneyt wrote:
On Thu, Aug 13, 2009 at 09:26:40PM +0200, Michael Van Canneyt wrote:
works well and does not require to much code changes, it could be wrapped
in
IFDEF's for more advanced users that want to try it for themselves.
Jürgen Hestermann wrote:
That's true. The general problem is not that the IDE is not
responsive when compiling/linking but that compiling/linking takes so
long.
FPC is a fast compiler and more speed is obviously also nice. The
compiling is not the issue to me, it's the unresponsive IDE that
On Fri, 14 Aug 2009 07:16:36 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
BTW, when the compiler has to read and write disk files, a separate
thread will not speed up much. Then the compiler thread will be
idle much time, waiting for disk I/O, and the main thread will be
Mattias Gaertner schrieb:
On Thu, 13 Aug 2009 22:24:37 +0200
Florian Klaempfl flor...@freepascal.org wrote:
Mattias Gaertner schrieb:
On Thu, 13 Aug 2009 14:01:38 +0200
Florian Klaempfl flor...@freepascal.org wrote:
Michael Van Canneyt schrieb:
So wouldn't it be more efficient to create a
Mattias Gaertner wrote:
-compiler crashes do not effect the IDE
I like Florian's idea too. As for your statement above, how often does
this really happen? In the last 4-5 years that I have been using FPC,
the compiler has not once crashed on me. Yes it might report that
there is a compiler
On Fri, 14 Aug 2009, Graeme Geldenhuys wrote:
Mattias Gaertner wrote:
-compiler crashes do not effect the IDE
I like Florian's idea too. As for your statement above, how often does this
really happen? In the last 4-5 years that I have been using FPC, the compiler
has not once crashed on
Graeme Geldenhuys wrote:
Jürgen Hestermann wrote:
That's true. The general problem is not that the IDE is not
responsive when compiling/linking but that compiling/linking takes so
long.
FPC is a fast compiler and more speed is obviously also nice. The
compiling is not the issue to me, it's
Mattias Gärtner schreef:
Zitat von Graeme Geldenhuys grae...@opensoft.homeip.net:
Mattias Gaertner wrote:
-compiler crashes do not effect the IDE
I like Florian's idea too. As for your statement above, how often does
this really happen? In the last 4-5 years that I have been using FPC,
Vincent Snijders wrote:
It may happen to me more than for you, because I may use the trunk
compiler more often, so that these things get noticed before it gets
in the release and more people are hurt.
That would be it. I stopped using the trunk compiler for our day-to-day
development. Plus
Graeme Geldenhuys wrote:
Martin wrote:
make it
if (Applicationnil) and
(abs(LastProcessMessages-Now)((1/86400)/10))
This does not make much difference on my system. :-(
Hm I tested on windows only. Try adding the 2 lines I inserted with
comments (I have not tested this!!)
Just
Michael Van Canneyt schreef:
On Fri, 14 Aug 2009, Vincent Snijders wrote:
Mattias Gärtner schreef:
Zitat von Graeme Geldenhuys grae...@opensoft.homeip.net:
Mattias Gaertner wrote:
-compiler crashes do not effect the IDE
I like Florian's idea too. As for your statement above, how often
sorry tested now.
doesn't work, outside windows world...
So even a blocking pipe should have some kind of CanRead that returns
immediately?
Martin wrote:
Graeme Geldenhuys wrote:
Martin wrote:
make it
if (Applicationnil) and
(abs(LastProcessMessages-Now)((1/86400)/10))
This does
Martin schreef:
Graeme Geldenhuys wrote:
Martin wrote:
make it
if (Applicationnil) and
(abs(LastProcessMessages-Now)((1/86400)/10))
This does not make much difference on my system. :-(
Hm I tested on windows only.
You can not really test it on windows, because on windows
Mattias Gärtner wrote:
Zitat von Vincent Snijders vsnijd...@vodafonevast.nl:
I like Florian's idea too. As for your statement above, how often
does this really happen? In the last 4-5 years that I have been
using FPC, the compiler has not once crashed on me. Yes it might
report that there is
Martin schreef:
Just out of curiosity, what are we trying to solve?
snip
Or am I missing some crucial point?
3 idle cores on a quad core CPU. Why pay for a quad core, if Lazarus + FPC use only
one? I am still waiting during a compile and those 3 other cores are idling. Let
them to part
Vincent Snijders wrote:
Or am I missing some crucial point?
3 idle cores on a quad core CPU. Why pay for a quad core, if Lazarus
+ FPC use only one? I am still waiting during a compile and those 3
other cores are idling. Let them to part of the work to get the job
done faster. ;-)
+10 :-) My
Vincent Snijders wrote:
Martin schreef:
Just out of curiosity, what are we trying to solve?
snip
Or am I missing some crucial point?
3 idle cores on a quad core CPU. Why pay for a quad core, if Lazarus +
FPC use only one? I am still waiting during a compile and those 3 other
cores are
Mattias Gärtner wrote:
Do you have time to debug TAsyncProcess?
No harm in trying...
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
--
___
Lazarus mailing list
Zitat von Martin laza...@mfriebe.de:
sorry tested now.
doesn't work, outside windows world...
So even a blocking pipe should have some kind of CanRead that
returns immediately?
Then it would be non blocking.
Mattias
--
___
Lazarus mailing
Zitat von Vincent Snijders vsnijd...@vodafonevast.nl:
Mattias Gärtner schreef:
Zitat von Graeme Geldenhuys grae...@opensoft.homeip.net:
Mattias Gaertner wrote:
-compiler crashes do not effect the IDE
I like Florian's idea too. As for your statement above, how often
does this really
On Friday 14 August 2009 10:48:05 Vincent Snijders wrote:
Graeme Geldenhuys schreef:
Mattias Gaertner wrote:
-compiler crashes do not effect the IDE
I like Florian's idea too. As for your statement above, how often does
this really happen?
It happens from time to time. For example:
On Friday 14 August 2009 08:55:07 Graeme Geldenhuys wrote:
Jürgen Hestermann wrote:
That's true. The general problem is not that the IDE is not
responsive when compiling/linking but that compiling/linking takes so
long.
FPC is a fast compiler and more speed is obviously also nice.
Last
On Fri, 14 Aug 2009, Martin Schreiber wrote:
On Friday 14 August 2009 08:55:07 Graeme Geldenhuys wrote:
Jürgen Hestermann wrote:
That's true. The general problem is not that the IDE is not
responsive when compiling/linking but that compiling/linking takes so
long.
FPC is a fast compiler
Florian Klaempfl wrote:
Probably simple. The compiler is started by the compile function in
fpc/compiler/compiler.pas and takes simply a command line arguments.
Florian, you were 100% correct, it is VERY easy! I looked at the FP IDE,
and within 5 minutes I had my own fpGUI based ide. :-)
Martin Schreiber wrote:
checking of the compiler output and the file search run in separate
threads, so MSEide is fully functional while compiling or searching.
Nice! :-)
From the MSEide config dialog, I gather MSEide also launches the FPC
compiler in a separate process and not built into
Vincent Snijders wrote:
Martin schreef:
Just out of curiosity, what are we trying to solve?
snip
Or am I missing some crucial point?
3 idle cores on a quad core CPU. Why pay for a quad core, if Lazarus +
FPC use only one? I am still waiting during a compile and those 3
other cores are
Martin schrieb:
Vincent Snijders wrote:
Martin schreef:
Just out of curiosity, what are we trying to solve?
snip
Or am I missing some crucial point?
3 idle cores on a quad core CPU. Why pay for a quad core, if Lazarus +
FPC use only one? I am still waiting during a compile and those 3
Martin schrieb:
and maybe add an application.idle(flase); too
Lazalus nevel makes things flase!
SCNL
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
2009/8/14 Martin Schreiber fp...@bluewin.ch:
On Friday 14 August 2009 13:22:01 Florian Klaempfl wrote:
It probably requires to rewrite FPC completely :) FPC chooses always
maintainability and portability over speed and compared with gcc or even
VS, FPC is still fast ;)
True, but the
On Friday 14 August 2009 13:41:30 Florian Klaempfl wrote:
Well, currently this does not help much either because FPC is mainly
bound to memory throughput if the disk cache is already hot. Resistent
FPC keeping units loaded would be the largest gain for projects like MSE
or Lazarus.
Really?
Martin Schreiber wrote:
From the MSEide config dialog, I gather MSEide also launches the
FPC compiler in a separate process and not built into the MSEide?
Yes. It can also call gcc and parse the error messages. Also possible
So how did you resolve the async process issue that Lazarus is
On Friday 14 August 2009 14:02:34 Graeme Geldenhuys wrote:
Martin Schreiber wrote:
Yes. It can also call gcc and parse the error messages. Also possible
So how did you resolve the async process issue that Lazarus is
experiencing under Linux? Or does running the compiler process (TProcess
Martin Schreiber wrote:
So does MSEide with the compile and the search in files function. The
checking of the compiler output and the file search run in separate
I just tried with a oldish MSEide 2.1 (unstable) and I monitored the
thread usage for the mseide process. You seem to use a few
Mattias Gärtner wrote:
Zitat von Graeme Geldenhuys grae...@opensoft.homeip.net:
Martin Schreiber wrote:
From the MSEide config dialog, I gather MSEide also launches the
FPC compiler in a separate process and not built into the MSEide?
Yes. It can also call gcc and parse the error messages.
On Thu, Aug 13, 2009 at 11:09:02PM +0200, Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
Does Delphi or Kylix have the compilers built-in or do they work similar
to Lazarus IDE?
AFAIK the Delphi IDE comes with an built-in compiler.
A dll. Not statically built in. Afaik cmdline
Martin Schreiber schrieb:
On Friday 14 August 2009 13:22:01 Florian Klaempfl wrote:
It probably requires to rewrite FPC completely :) FPC chooses always
maintainability and portability over speed and compared with gcc or even
VS, FPC is still fast ;)
True, but the distance will be less with
On Fri, Aug 14, 2009 at 09:19:11AM +0200, Mattias Gaertner wrote:
And having compiler and linker in separate (asynchronous) threads
would be the same as starting them as a new process in asynchronous
mode. It would open a can of worms because of synchronising problems.
They only share
Martin Schreiber schrieb:
On Friday 14 August 2009 13:41:30 Florian Klaempfl wrote:
Well, currently this does not help much either because FPC is mainly
bound to memory throughput if the disk cache is already hot. Resistent
FPC keeping units loaded would be the largest gain for projects like
On Friday 14 August 2009 14:23:36 Graeme Geldenhuys wrote:
Martin Schreiber wrote:
So does MSEide with the compile and the search in files function. The
checking of the compiler output and the file search run in separate
I just tried with a oldish MSEide 2.1 (unstable) and I monitored the
On Fri, Aug 14, 2009 at 09:37:56AM +0200, Michael Van Canneyt wrote:
-various compiler versions
-compiler crashes do not effect the IDE
Good enough for me NOT to do it. If the compiler was internal to the
IDE, I could not easily compile for 32/64 bit or a different version,
without
On Friday 14 August 2009 14:24:53 Mattias Gärtner wrote:
I have some small programs with one thousand lines in the main source
and using units with about 30k loc. Recompile and linking the program
takes less than a second.
With small I mean 100'000 lines. ;-)
Martin
--
On Friday 14 August 2009 14:51:04 Florian Klaempfl wrote:
Martin Schreiber schrieb:
True, but the distance will be less with every FPC release if compiling
speed is not observed I fear.
The possibility of Delphi to compile big projects in some seconds and
small projects in less than a
2009/8/14 Martin Schreiber fp...@bluewin.ch:
MSEide (330k lines) needs 25s on Athlon 64 X2. Commandline:
ppc386 -B
apps/ide/mseide.pas -Fulib/common/* -Fulib/common/kernel/i386-linux
-Fi/lib/common/kernel
25 s is too much to wait and too little to sleep. ;-)
How long does fpc -sh take?
On Friday 14 August 2009 16:14:16 Henry Vermaak wrote:
2009/8/14 Martin Schreiber fp...@bluewin.ch:
MSEide (330k lines) needs 25s on Athlon 64 X2. Commandline:
ppc386 -B
apps/ide/mseide.pas -Fulib/common/* -Fulib/common/kernel/i386-linux
-Fi/lib/common/kernel
25 s is too much to wait
Martin Schreiber wrote:
25 s is too much to wait and too little to sleep. ;-)
I so agree with that! :-)
Same command line params as yours - on a Intel P4 2.4Ghz.
322187 lines compiled, 33.6 sec
And with the -sh parameter.
322187 lines compiled, 28.7 sec
Martin, how does your results
Martin schreef:
Mattias Gärtner wrote:
No. Just write a ThreadedProcess. That would work pretty much like
TAsynProcess.
And I guess it will suffer the same bug.
I don't know what you mean by ThreadedProcess unless you meant yes,
but wanted to indicate a different form of implementation?
Vincent Snijders wrote:
I have looked a bit more why outputfilter is so slow at parsing a lot
of compiler output (e.g. compiling a simple LCL app with -va). The
pipe buffer is rather small, NumBytesAvailable is not bigger than 1280
bytes. So OnAsyncReadData reads only 1280 bytes at a time.
On Fri, 14 Aug 2009, Graeme Geldenhuys wrote:
Martin Schreiber wrote:
25 s is too much to wait and too little to sleep. ;-)
I so agree with that! :-)
Same command line params as yours - on a Intel P4 2.4Ghz.
322187 lines compiled, 33.6 sec
And with the -sh parameter.
322187 lines
The loop in outputfilter can be simplified quite a bit
All the extra handling of the asyncprocess can be reduced to the
following lines (the event handlers can be removed):
if fProcess is TAsyncProcess then begin
Count:=TAsyncProcess(fProcess).NumBytesAvailable;
if
On Friday 14 August 2009 16:58:40 Graeme Geldenhuys wrote:
Martin Schreiber wrote:
25 s is too much to wait and too little to sleep. ;-)
I so agree with that! :-)
Same command line params as yours - on a Intel P4 2.4Ghz.
322187 lines compiled, 33.6 sec
And with the -sh parameter.
Martin Schreiber wrote:
Martin, how does your results compare when you use Delphi's bcc32 compiler?
http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg08029.html
Wow, that is a sizeable difference. I did not realize the Delphi compiler was
that fast.
Regards,
- Graeme -
Graeme Geldenhuys schreef:
Hi,
Does the Lazarus IDE use multi-threading for anything? Will it take
advantage of a Quad Core processor?
The IDE itself is single threaded.
Examples where I think it could be used (if not already)
- background parsing of units
- fpdoc lookups
- compile
Graeme Geldenhuys wrote:
Hi,
Does the Lazarus IDE use multi-threading for anything? Will it take
advantage of a Quad Core processor?
Examples where I think it could be used (if not already)
- background parsing of units
- fpdoc lookups
- compile project in separate thread (currently the
Graeme Geldenhuys schreef:
Marc Weustink wrote:
Don't know about the others, but compiling is done by a separate
process, so there is a chance that your os runs it in a different core.
That's not the same as running it in a separate thread though - is it?
Quoted from a Posix Thread
On Thu, 13 Aug 2009, Graeme Geldenhuys wrote:
Marc Weustink wrote:
Don't know about the others, but compiling is done by a separate process,
so there is a chance that your os runs it in a different core.
That's not the same as running it in a separate thread though - is it?
Quoted from
Graeme Geldenhuys wrote:
How can I see the thread-count per process / application under Linux?
To answer my own question...
$ watch -n.1 'ps -C thunderbird-bin -L -o pid,tid,pcpu,state'
This will execute the ps command every second showing a live update of
the threads for the
Michael Van Canneyt schrieb:
So wouldn't it be more efficient to create a new thread for the
compiler instead of a new process?
Efficient, yes;
As I pointed out on fpc-core a few days ago, I'd like to create an fpc
which stays in memory and takes commands via pipes/sockets/ipc whatever
to
I published and provided source for Manager and Worker Threads. It
includes advanced knowledge on how to design a highly efficient system
with little to no wait-states.
See: http://wiki.freepascal.org/Manager_Worker_Threads_System
Let me know what you think,
- Andrew
On Thu, Aug 13, 2009 at
On Thu, 13 Aug 2009, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
So wouldn't it be more efficient to create a new thread for the compiler
instead of a new process?
Efficient, yes;
As I pointed out on fpc-core a few days ago, I'd like to create an fpc which
stays in memory and
Graeme Geldenhuys schrieb:
Quoted from a Posix Thread tutorial I found on the internet.
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
Threads require less overhead than forking or spawning a new process
because the system does not initialize a new system virtual memory
On Thu, Aug 13, 2009 at 02:01:38PM +0200, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
So wouldn't it be more efficient to create a new thread for the
compiler instead of a new process?
Efficient, yes;
As I pointed out on fpc-core a few days ago, I'd like to create an fpc
Marc Weustink wrote:
Don't know about the others, but compiling is done by a separate
process, so there is a chance that your os runs it in a different
core.
OK, after reading all the other responses I now understand the
flexibility of keeping FPC and Lazarus separate, but why then is
OK, after reading all the other responses I now understand the flexibility
of keeping FPC and Lazarus separate, but why then is Lazarus non-responsive
while the compiler is compiling in a separate process?
because IDE is reading FPC output?
and gives only a few .ProcessMessages for user
Vincent Snijders wrote:
Yes, it is more efficient. The fp ide also doesn't create a new process.
Interesting, I'll take a peak at that.
The disadvantage of using the same process is that the coupling is much
tighter: No easy switching between compiler versions, and crashing the
compiler
Can somebody that is more familiar with the internals of the Lazarus IDE
tell me, would it be hard to implement the IDE with FPC built in, so that
compiling can be done in a separate thread instead of separate process? I'll
do the work of course - if it's not a major job. ;-)
The most hardest
On Thu, 13 Aug 2009, Graeme Geldenhuys wrote:
Vincent Snijders wrote:
Yes, it is more efficient. The fp ide also doesn't create a new process.
Interesting, I'll take a peak at that.
The disadvantage of using the same process is that the coupling is much
tighter: No easy switching
Graeme Geldenhuys schrieb:
Vincent Snijders wrote:
Yes, it is more efficient. The fp ide also doesn't create a new process.
Interesting, I'll take a peak at that.
The disadvantage of using the same process is that the coupling is
much tighter: No easy switching between compiler
On Thu, 13 Aug 2009 12:40:54 +0200
Graeme Geldenhuys grae...@opensoft.homeip.net wrote:
Hi,
Does the Lazarus IDE use multi-threading for anything?
It is single threaded.
Will it take advantage of a Quad Core processor?
Not yet.
Examples where I think it could be used (if not already)
On Thu, 13 Aug 2009 14:01:38 +0200
Florian Klaempfl flor...@freepascal.org wrote:
Michael Van Canneyt schrieb:
So wouldn't it be more efficient to create a new thread for the
compiler instead of a new process?
Efficient, yes;
As I pointed out on fpc-core a few days ago, I'd like to
Mattias Gaertner schrieb:
On Thu, 13 Aug 2009 14:01:38 +0200
Florian Klaempfl flor...@freepascal.org wrote:
Michael Van Canneyt schrieb:
So wouldn't it be more efficient to create a new thread for the
compiler instead of a new process?
Efficient, yes;
As I pointed out on fpc-core a few
On Thu, 13 Aug 2009 22:24:37 +0200
Florian Klaempfl flor...@freepascal.org wrote:
Mattias Gaertner schrieb:
On Thu, 13 Aug 2009 14:01:38 +0200
Florian Klaempfl flor...@freepascal.org wrote:
Michael Van Canneyt schrieb:
So wouldn't it be more efficient to create a new thread for the
Michael Van Canneyt wrote:
They have the compiler in a DLL which is loaded when the IDE starts.
Clever. I would imagine their command line compiler also uses that DLL then.
Simple code reuse.
Regards,
- Graeme -
fpGUI - a cross-platform
Florian Klaempfl wrote:
Probably simple. The compiler is started by the compile function in
fpc/compiler/compiler.pas and takes simply a command line arguments. You
need to set some hooks though to catch messages, see e.g.
fpc/ide/fpcompile.pas (especially DoCompile starting at 868) and
Mattias Gaertner wrote:
Examples where I think it could be used (if not already)
- background parsing of units
Yes, this is planned. Some expensive parts can be done in worker
Excellent.
- fpdoc lookups
That should be easier. This already works in several separate parts
executed
74 matches
Mail list logo
