Hi FPC experts.
I read this thread in the list archive and as I'm very interested in
this topic (since years), I'm very happy do see this evolving and would
like to provide some comment (and maybe contribute some code once I'm up
to speed with FPC) and, of course, ask questions.
1) How is
It does.
Great !
None currently. Only 'Synchronize' is implemented.
Like with Delphi :-) :-( .
Feel free to implement this, but not as a language enhancement, a simple
unit should be enough.
..., at least for the beginning !
I'm sure I'll do this (supposedly in
Really ? Does TThread.Suspend work on linux ?
IMHO, the need for this function means your design is broken, but
maybe it's just me ...
As Delphi does provide TThread.Suspend, I suppose FPC should do so on
any platform (unless that is really impossible, which I don't think).
Of course you
..., at least for the beginning !
Why ? You don't need language enhancements for this IMHO. Scheduling and
messaging is OS territory, not programming language territory.
e.g. Ada provides multithreading means as language elements and AFAIK,
other languages also provide
If the Eventer class in lNet can be moved into general FCL this would
be possible because I was planning to create a TLTimer, for use with
lNet eventer.
Could you elaborate on that (I don't know what lNet is at the moment).
But IMHO there should not be a separate TLTimer but the RTL (that
lNet is
a networking library, and has an internal event loop already
implemented, cross-platform.
Wouldn't it b e better to first implement an independent cross-platform
event loop ("Application!" thingy) in the RTL that can be used by
TTimer, TThread.Synchronize and lNet ?!?!?
If
Remember you need to call the HandleEvents as fast as possible to
stay effective (otherwise you lose precision)
I want to avoid this by any means !
That is why I want to have a message driven system (as described in the
other post):
TAppllication creates an event from a message
I can't call callbacks in threads? Why's that? Or am I understanding
something wrong?
Of course you can use "events" (aka class properties that are
functions) in threads. That is just the Object Pascal syntax. But in
the main thread in Delphi or Lazarus events of GUI objects (e.g.
I don't
even care, because I simply don't understand what time as in timer
has to do with graphics as in graphical. For me that's two
completely different subjects unless we're talking about animations
where those two subjects meet.
Viewing from top you are right, and I do need a platform
The big advantage is that you do not need to protect any resources
from multi-threaded access if you do not explicitly create a thread
by means of TThread.
And the big disadvantage seems to be a overly complicated programming
model. Guess, what I'd prefer.
As said, we
MSEgui has teventthread (lib/common/kernel/msethread.pas), there is also a
timer implementation (lib/common/kernel/msetimer.pas).
http://mypage.bluewin.ch/msegui/
Thanks for the pointer. I'll take a look at this tomorrow.
What is the purpose of msetimer ?
Do you think this can show a
As for general use, you can't do a Timer this way.
Right ! The beauty of TTimer (and GUI events as well) is that it does
not work in a thread. Otherwise it e.g. would not be possible to do GUI
stuff in a timer event, as VCL and LCL are not thread save (and probably
can't be made thread
Vinzent Hoefler wrote:
On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
Of course, because the common concept of a timer is as asynchronous
as in "multi-threaded" or even "interrupt".
That is not true ! (See my other post.)
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication
descends
from it. All you need to do is create a descendent of TCustomApplication which
can implement all the messaging you wish for...
That sounds very good. :-) I'll take a look at this. (Supposedly in
January
I even call the callback of another thread. :P
No you can't.
You still refuse to tell me why, so please stop telling me what I can't
do, especially when I *am* doing it.
Of course you can call any callback that exists in the application from
It all depends on what you're trying to accomplish. I still like to have
a asynchronous timer event model. It would still simplify some code.
You are right that this would be desirable.
Normal Delphi/Lazarus like TTimers are non-preemptive (you may call it
synchronous) for a good reason
It can't because X-Windows or MS-Windows are not thread-safe.
Yeah, right. And threading in DOS is not possible either, because DOS
is non-reentrant, is it?
You _can_ use threads in an X-Windows, MS-Windows or DOS environment,
you just can't do X-Windows, MS-Windows
Well, I don't consider it beautiful, I consider it a hack. :)
It's beautiful, as the user does not need to care about mutually exclude
access of the objects that are used both in the main line code and the
timer callbacks. Most application programmers would not be able to
deal with this
But now ... rereading the post, the original text was You can't just
put a TTimer in which works in it's own thread and then calls some
callback in it's own thread, and I still wonder why I shouldn't be
able to do that (well, if TTimer would actually do what its name
suggests and no-one else
Sorry, if it caused confusion, ...
No problem, taking more ideas as an input is always useful !
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Also I think a base thread should remain free from this. You can of course
create a descendant of tthread that is event driven (e.g. messagequeue, pump
and list of known events/methodvars in overriden tthread.execute)
Right. That is a decent way to do it optionally (as I of course would
do
Separate event scheduler and application.
Hint registered and saved in the to-do list :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
This is not an async timer in the way Vincent meant it, assuming I
read his mails correctly. Also, pre-emptive multitasking is different
from the async timer as you're explaining here in exactly this detail.
An asynchronous timer needs to do a preemptive callback. Preemptive
execution needs
Micha Nelissen wrote:
Michael Schnell wrote:
An asynchronous timer needs to do a preemptive callback.
No.
Ooops ? What is an asynchronous timer according to your definition ?
Preemptive execution needs it's own thread.
No.
Ooops ? What do you think is preemptive ? By definition
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication
descends
from it. All you need to do is create a descendent of TCustomApplication which
can implement all the messaging you wish for...
I took a look at TCustomApplication. Same does not provide anything that
is
Michael Van Canneyt wrote:
TThread.Synchronize does not need to be changed. You can set a series
of callbacks (from classes unit) which you can then use to configure
the whole synchronize issue...
Sounds great !
Seems correct. And all this cross-platform, of course :-)
Of course !!!
The answer to my I always thought a timer is more comparable to an
interrupt or signal than a polling loop. was That is a very common
misconception. which I still refuse as being a correct answer.
I misunderstood that you meant a Delphi TTimer. And I wanted to point
out that many Delphi
Your code can perfectly be implemented as an add-on unit, which we can
distribute.
The first goal I see is that FPC comes with portable support for TTimer
and Delphi/Lazarus compatible thread support, that can be used in a
GUI-less Application - thus without Lazarus. If that's possible
Yes, of course, this still *is* nothing more than an event loop, ...
A decent event loop should use an OS API to free the processor until the
next event is scheduled:
Meta code:
repeat
if (event in event queue) begin // this is either an OS API call or
the event queue is done with user
Alas, Object Pascal
lacks a decent portable OS tasking interface.
With Delphi we successfully used Windows Messages for inter Thread
communication.
With FPC on Linux a friend of mine used System 5 Messages queues for the
same purpose.
So IMHO inter Thread messages is a good way to go.
Why don't you simply go ahead, implement something (cross-platform) and then
we can see how this can be integrated in FPC, if this integration is needed at all...
I did do first steps of this already some years ago. I hope I will be
able to start over in January.
-Michael
BTW.:
TPC comes with Free Vision.
The FPC IDE based on Free Vision seems to work fine.
The Free Vision Non-GUI seems to be event driven and thus needs to
implement a kind of event scheduler.
Maybe same might be worth looking at.
-Michael
___
It might be perhaps better to wait until the whole ThreadManager problem
is solved one way or the other.
What exactly is the ThreadManager problem ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
If you got a nice idea come up with it coz I'm kind of lost.
First thing that comes into my mind:
Use a TP-specific propriety integer value as a result and store the OS
specific value in an OS specific property so that it can be checked if
the user really needs to.
The OS specific
Do I need to add/define something when I build the crosscompiler to get
softfloat support?
Is changing system_arm_linux_info.endian to endian_big in
fpc/compiler/systems/i_linux.pas enough?
In theory yes, in practice probably not.
In the ARM-Linux developers list I have been told that
BTW.
On the long run I am interested in making (embedded) FPC programs run on
(our own) ARM-hardware.
I only found notice about FPC programs for PDAs. Am I right assuming
that there is no special problem using a displayless ARM9 device (like a
slug) for FPC programs ?
-Michael
BTW.
On the long run I am interested in making (embedded) FPC programs run on
(our own) ARM-hardware.
I only found notice about FPC programs for PDAs. Am I right assuming
that there is no special problem using a displayless ARM9 device (like a
slug but low endian) for FPC programs ?
-Michael
BTW.
On the long run I am interested in making (embedded) FPC programs run on
(our own) ARM-hardware.
I only found notice about FPC programs for PDAs. Am I right assuming
that there is no special problem using a displayless ARM9 device (like a
slug but little endian) for FPC programs ?
-Michael
I'am currently preparing the rtl for embedded purposes. Of course, using FPC on
an embedded device isn't install and play like on common OSes simply because
embedded devices differ and there is no real standard regarding output format.
But it should be doable.
Great !
Thanks. Please keep
Is there any documentation on simpleipc ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Will fpc support generic record declarations like this:
type
generic TFixedKeyNodeKeySize = record
key: array[0..KeySize-1] of char;
value: dword;
end;
In other word the type is not parameterized by another type but by an
integer used to define the upper limit of an array.
Free
Your problem isn't that the sqldblaz.ppu isn't there, but that sqldb
isn't compiled at all on a wince-target. So it's not available, and thus
Lazarus can't build the wrapper.
BTW.: Is sqldb available for Linux on PC and ARM ?
-Michael
___
Michael Schnell schreef:
No. Generics are more like using a macro when defining a type.
So a := copies the memory and not a pointer and they are passed by
value into a procedure.
I think you cut too much context. To which question does this give an
answer?
(Don't you see the link
I have created a arm-wince cross compiler installer for lazarus-win32:
ftp://ftp.hu.freepascal.org/pub/lazarus/cross/Lazarus-0.9.21-fpc-2.1.1-20070103-cross-arm-wince-win32.exe
In what way is the arm-wince cross compiler related to the arm-Linux
cross compiler (the one I some day would
I have created a arm-wince cross compiler installer for lazarus-win32:
Nokao tried to use it, but he is getting errors:
http://www.lazarus.freepascal.org/index.php?name=PNphpBB2file=viewtopict=3255
(using fpc from 30-12-2006)
Hi Vincent,
While I was positive that it should be possible
I think GDB for arm-wince should be included to cross installer:
ftp://ftp.freepascal.org/pub/fpc/contrib/cross/gdb-6.4-win32-arm-wince.zip
I will do this in the future.
Vincent
Great !
What about cross compiling from Linux to ARM-Linux (or even from Windows
to Arm Linux). Or cross PC
Let me know, if you want to try this out, then I can try to build an
installer for cross-arm-linux.
Vincent
Great !
As you might have noticed I'm planning to do a major embedded Project on
Arm Linux (porting a lot of Delphi stuff), but it's not yet decided
if/when it is going to be
Let me know, if you want to try this out, then I can try to build an
installer for cross-arm-linux.
Vincent
I suppose my favorite would be cross-compiling from PC-Linux top ARM-Linux.
-Michael
___
fpc-devel maillist -
I hope i helped you in some way ;)
Of course ! :-) :-) :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ftp://ftp.hu.freepascal.org/pub/lazarus/cross/Lazarus-0.9.21-fpc-2.1.1-20070104-cross-arm-linux-win32.exe
What difference does the .hu make (seemingly none)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
I am not sure if we understand each other completely, so let me write
my (personal) view on these things.
:-) see below...
FPC is a great compiler, which also can target several OS-es on the
arm processor (linux, wince, gba and lately nintendo ds).
Sounds great !
I want Lazarus to be
When doing cross projects remote debugging always comes into mind.
Can Lazarus do remote debugging at all ?
Is same possible / planned to be possible with ARM Linux targets ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
See
http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/docs/RemoteDebugging.txt?root=lazarusview=markup
Note its date. So it might need to be updated or it might still work.
Step 5: Setup the ssh debugger in the IDE
ToDo
That does not help much ;-)
-Michael
I guess not much help is needed. Just open the Debugger Options and
select GNU debugger through SSH (gdb), would be my first guess.
Never done this though.
Great (sorry for my being cynical :-[ ) !
So I gather that you are convinced that it does work as well PC-PC as
PC-ARM (Linux and
That doesn't work when debugging from with lazarus, since you cannot
specify the target.
When debugging through ssh, you only need ssh access to your target and
be able to run gdb on your target. That all
So SSH opens a (bash) session that starts gdbserver with the appropriate
parameters
Graeme Geldenhuys wrote:
Hi,
Is this documentation outdated?
http://lazarus-ccr.sourceforge.net/docs/rtl/classes/tthreadlist.html
It states: Thread-safe list object (not yet implemented).
..but yet it looks implemented to me...
It seems like only a few lines of code to make TThreadList
2) make the ttimer work on wince, so he can call the CallAction
function that manages the connection sometime indipendently from the
application. That would be a workaround (so useful for me) but not the
definitive solution for lnet.
TTimer does not work on WINCE ?!?!?
If this is the case,
Thanks for the clarifying statement, Peter
I's obvious that linking Object Pascal and C++ in that way is not possible.
OTOH, is interfaces not invented for object based inter-language
communication ?
So an interface based DLL layer, converting the C++ API of the OS to
interfaces FP could
As far as I remember, Delphi 5 and on has an IDL compiler included,
I suppose same is used to generate an interface unit when you do import
type library. Is this possible with TP, too ?
and can generate IDL code from an Object Pascal hierarchy.
I suppose this is true and necessary when
I recommend installing Linux on your desktop computer, which costs you
much less time to accomplish than building a cross-compiler.
For compiling for ARM a cross compiler is necessary anyway, but
nonetheless I feel that when doing work for Linux it's a good idea to
use Linux as an
Hi Experts.
I'm aiming to create non-GUI applications (not command line programs,
i.e. applications that can use event driven programming with TTimer,
TThread.Synchronize etc.) using Free Pascal (and Lazarus).
When looking into that I found that I need to derive a new class
What does the compiler do when translating procedure ... message ?
I need to know this as I want to create a non-GUI workalike of the
TApplication class that can do things like TTimer
TThread.Synchronize, Message events, etc, using Windows messages in
Windows (for testing purpose) and system
peter green wrote:
What does the compiler do when translating procedure ... message ?
I need to know this as I want to create a non-GUI workalike of the
TApplication class that can do things like TTimer
TThread.Synchronize, Message events, etc, using Windows messages in
Windows (for testing
I see you are still a bit lost. Maybe the documentation can help:
http://www.freepascal.org/docs-html/ref/refsu24.html
I in fact am lost (as I still don't dare to try to look into the
compiler's source code).
Unfortunately the docs text does not say what code the compiler
generates to make
What happens is that the compiler creates
an try in the message table of the RTTI for the class. Check out the
implementation of Tobject.Dispatch to see how that is used.
Thanks. That seems to give me a clue. I have no idea what creates a
try means but maybe I'll find out.
Thanks again,
See implementation of dispatch. It gets the message number and looks
for the corresponding method in a table. The compiler generates this
table at compile time.
Thanks. I did try to find it but am lost up till now. regarding
Thorsten's message I assume it is a member function to some class
Thorsten Engler wrote:
Thanks. That seems to give me a clue. I have no idea what
creates a try means but maybe I'll find out.
Should have been an entry
Sorry for not guessing this :-\ .
Now I need to find out what exactly it puts into the RTTI and how to
extract it from there.
Also I
creates an entry most probably.
Right. Thanks.
-Michael (not a native speaker :-( )
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Thanks. I did try to find it but am lost up till now. regarding
Thorsten's message I assume it is a member function to some class
(e.g. TObject), but my usual means to find such functions don't show
it to me.
Sorry.
Found it !
Thanks again.
-Michael
I was told that in the next not yet released Lazarus version there will
be a platform independent feature that lets you create daemons
(applications without user interface).
I need to do something like this.
Is there any documentation on how this works ?
Is the sourcecode available somewhere
Michael Van Canneyt wrote:
On Tue, 13 Feb 2007, Michael Schnell wrote:
I was told that in the next not yet released Lazarus version there will be a
platform independent feature that lets you create daemons (applications
without user interface).
I need to do something like
Somewhere user code must call
MyObject.Dispatch(MyMessage);
This looks as if this might be good news. The dispatch mechanism seems
to be completely platform independent and so it seems I just need to
fire the normal (obviously hierarchical) dispatch mechanism when a
message arrives.
Using TortoiseSVN I get could not connect to server
(http://snv.freepascal.org) if I try to do SNV checkout.
p.s. Does TortoiseSVN use the proxy configuration from Explorer ? With
http://snv.freepascal.org Explorer does show me the Free Pascal home page.
-Michael
There is a typo: use http://svn.freepascal.org
Right That is what I did. with the correct address I get the error
message after a waiting time of about a minute. Using a wrong address
(like snv...) I get a different error message within a second.
So the DNS can resolve the name.
-Michael
The URL for tortoiseSVN is
http://svn.freepascal.org/svn/fpc/trunk
Right. That is exactly what I did.
The other error message I got was PROFIND request failed on
'/svn/fpc/trunk'.
The long delay before the error is displayed suggests that the server
does not answer at all - not even with
This has happened before and some people could work around it using
the port 8080.
Setting the proxy in servers in fact started the communication to the
SVN server.but nonetheless it ends up with an error (see the other mail)
Error REPORT request failed on '/svn/fpc/!svn/vcc/default'
This (HTTP error 400) most probably indicates the broken proxy scenario
mentioned by Vincent.
So I supposedly am lost :(
.Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Lee, John wrote:
Saw somwhere (I think) that there is/may be a problem with later versions of SVN client re using proxies...FWIW I'm using svn CL 1.4.2 tortoise 1.1.7 to access fpc svn, from behind firewall with proxy, port 80 - our proxy doesnt need any other authentication- it works ok.
I tried the simpleipc unit supplied with freepascal to try and eliminate
the the file based IPC I wrote - but in Linux - it was awful - and
seemed to have symptoms of thread safety - could be my end or FPC rtl -
I'm not sure.
I understood that you use multiple _programs_. If you use multiple
I have a big project in c,and i wanted to somehow use
it in fpc,so i compiled the code with evc(embedded
visual c compiler 4.0 of microsoft)and linked it to my
pascal code.
Why do you think it's possible to link the evc output with something
that is not compiled using evc ? What linker is
Did you see
http://www.linuxdevices.com/news/NS4545938946.html
?
Might this help ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
HI FP experts.
Is there any decent chance that there is or that it's possible to create
a cross compiler to run FP programs on an Analog Devices BlackFin CPU
that runs the appropriate Linux distribution ?
-Michael
___
fpc-devel maillist - [EMAIL
No. Not without pushing a port to it in some way.
Thanks. And I suppose doing a port for that processor would be quite a
lot of work, regarding the ASM code is very strange if you compare it to
the code of 80x86, PPC or ARM.
-Michael
___
Florian, Thanks a lot for discussing this !
Well, this depends how good one wants to make such a port ...
In this case the (first version of the) port does not need to be very
good (in the sense of creating optimized code), but of course the
compiler needs to produce correct code that
r2 = r1 + r3, r4 = dm(i0,m1); /* addition and memory access */
Yep. In my answer to Florian I forgot that (other than ARM) the Blackfin
can do a calculation and a memory access in a single instruction cycle.
That explains the much better performance even with standard
(non-DSP-alike)
We have to start a research hardware project end of may, and
are also in the middle between choosing an ARM/FPC way or
a blackfin/non fpc way. This discussions opens a new possibility, which
I would gratly favour.
Great to know that I am not the only one ! :-)
-Michael
If you're interested, start a wiki page with some information where to
get docs, tools, info about calling conventions etc.
Thanks for the encouragement !
Next month I'll see an FAE who just started supporting the BlackFin
line. After that I hope I can see a bit clearer.
-Michael
We already have the generics can the preprocessor symbols. That leaves the
for in. The development team has its doubts about the for in
construct, but:
* Andreas did it in a reasonably clean way with a lot less hacks and
ugly constructions than Delphi did.
* The pressure on us is
Felipe Monteiro de Carvalho wrote:
What is the architecture of NIOS/2 ? Something standard or it has it's
own design for opcodes, registers, etc?
It's a propriety design of Altera's and seems a little bit similar to ARM.
The NIOS is a very standard RISK processor with load/store architecture
Michael Schnell wrote:
Does Delphi really rebuild all units, then ?
No, it does not.
Of course it does do a decent make process.
But for me it does a link when I press F9 just to restart the
program again when debugging. Why is this necessary ? (Delphi just
start the program here
Make is not used, unless you rebuild lazarus.
I see.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
If you trust Lazarus to make the right decision when determining if something is changed, then
go to Project - Project Options - Miscellaneous and uncheck Always build (even
if nothing changed).
I see,
Thanks,
-Michael
___
fpc-devel maillist
The website is outdated, but the mailing list recently became quite active
again
Great !
- including flamewars.
not that great ;-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Michael Van Canneyt wrote:
On Mon, 23 Jul 2007, Michael Schnell wrote:
Yes. They're working full-time on it, it seems.
.. and seem to have a person working completely on this.
Will it become a commercial product ?
-Michael
___
fpc
It's asm, it should be faster than pascal code.
I don't think that this makes a noticeable difference.
IMHO the main speed difference is the count of calls to graphic
primitives that are done internally in the display card hardware (such
as draw pixel, draw line, draw rectangle, draw
isn't that the basis
for any software implemented graphics routine: drawing pixels ?
No.
That is what the graphic card hardware does. The software requests same
to do graphic primitives (like draw rectangle, draw line, copy
rectangle). As the main bottleneck is the interface between the
Because the files inside it are .tar.gz files, so no compressing again is
pointless.
That is of course correct,
But taring first and compressing afterwards should result in smaller
files, as more identical patterns can be found and many basic patterns
need not to be stored multiple
I want to know how to build Freepascal so it runs on SPARC,
MIPS(EL) and ARM GNU/Linux. For the latter two I will probably
first have to cross-build to these architectures if possible but I
don't know how to do this yet.
AFAIK cross compiling for ARM/Linux already is fully supported (though I
I was just reading the forums. Someone has largely ported
FPC to little-endian MIPS, so I will try to contact him.
Please let me know about what you find !
The lack of memory on ARM targets is not really a problem at all.
I have QEMU virtual machines for various architectures and I can
Luca Olivetti wrote:
En/na Michael Schnell ha escrit:
Do you think it's really essential to have the compiler run on the
target ? Cross-compiling should be much easier to do and a lot easier
to work with for the users. (Is anybody really supposed to write
programs on his PDA ? )
Well, my
1 - 100 of 1709 matches
Mail list logo
