One day (In a far far away future) I will understand how this whole
compiler magic works ;-)
Thank you very much for your fix, the LED's on my Board are not (yet)
blinking, but at least now the code seems to run fine in gdb.
Have a nice evening, will contact you when I have a little more code
Should be fixed now. The cpupi code estimated that it needed a copy of
the TGPIO_Registers record on the stack even though it was passed by
reference :)
Den 14-01-2014 09:47, Michael Ring skrev:
I have boiled down my problem to this democode. The problem is in the
begin line of set Direction.
@
Hinst, Michael, Tomas, Mark, Lukasz, Ewald, Marco, Sven and Waldo :
MANY, MANY THANKS.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pasca
> I identified the problem
Mr Hint : you are magic...
I cannot find words...
1.000 gigas of thanks ( even more...).
Of course you get a big credit in uos project.
Fred
___
fpc-pascal maillist - f
On Tue, 14 Jan 2014, Sven Barth wrote:
Am 14.01.2014 09:24 schrieb "Sven Barth" :
> Maybe an overload could be added to load functions by ordinal on Windows and
which simply returns Nil on other platforms.
I've now added an overload which is implemented for the Windows systems and
returns
Am 14.01.2014 09:24 schrieb "Sven Barth" :
> Maybe an overload could be added to load functions by ordinal on Windows
and which simply returns Nil on other platforms.
I've now added an overload which is implemented for the Windows systems and
returns Nil on other targets.
For Delphi compatibility
Am 14.01.2014 13:21 schrieb "Fred van Stappen" :
>
> >Now, for the windows version, I don't know what underlying mechanism
> >dynlibs uses under windows, so I'm afraid I can't really comment on that
>platform, except that you could try a similar approach as on linux (use
symbol
> >names instead of
Am 14.01.2014 14:02 schrieb "Tomas Hajny" :
>
> On Tue, January 14, 2014 09:24, Sven Barth wrote:
> > Am 14.01.2014 00:12 schrieb "Ewald" :
> >> On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
> >>
> >>> The SoundTouch.dll uses index to call the procedures.
> .
> .
> > No, ordinals are not supp
On Tue, January 14, 2014 09:24, Sven Barth wrote:
> Am 14.01.2014 00:12 schrieb "Ewald" :
>> On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
>>
>>> The SoundTouch.dll uses index to call the procedures.
.
.
> No, ordinals are not supported on non-Windows (or more precisely non-PE)
> systems.
Th
I identified the problem
Take a look at the function declaration plz:
Function GetProcAddress(Lib : TlibHandle; const ProcName : AnsiString) :
Pointer; // from dynlibs
It internally uses this function:
Function GetProcedureAddress(Lib : TLibHandle; const ProcName : AnsiString) :
Pointer;
On 01/14/2014 12:59 PM, Mark Morgan Lloyd wrote:
They'll get a TERM first, and five seconds later a KILL. You don't
want to restart after that first signal, because if you wait until the
second one you risk leaving files etc. associated with the program in
an indeterminate state. I've had Qem
> fred, can you please adjust your quoting to use the standard '>' for previous
> responses and then add your response below? you do add your response below
> but
> the quote is the exact of the previous and it is very hard to read only your
> responses when the previous is not prefixed by '>'.
>Now, for the windows version, I don't know what underlying mechanism
>dynlibs uses under windows, so I'm afraid I can't really comment on that
>>platform, except that you could try a similar approach as on linux (use symbol
>names instead of indices). OTOH it could (?) be that the the compiler in
On 01/14/2014 12:59 PM, Mark Morgan Lloyd wrote:
They'll get a TERM first, and five seconds later a KILL. You don't
want to restart after that first signal, because if you wait until the
second one you risk leaving files etc. associated with the program in
an indeterminate state. I've had Qem
Michael Schnell wrote:
On 01/14/2014 12:07 PM, Mark Morgan Lloyd wrote:
You need to make sure that it doesn't try to restart if it's received
a signal that the system's going down
I suppose the bash running the "loopmyprogram" script will get the kill
signal, as well and stop right away.
T
Am 14.01.2014 12:04 schrieb "Marco van de Voort" :
>
> In our previous episode, Sven Barth said:
> >
> > Maybe an overload could be added to load functions by ordinal on Windows
> > and which simply returns Nil on other platforms.
>
> I thought the index feature originated in win3.x and was mostly
On 01/14/2014 12:07 PM, Mark Morgan Lloyd wrote:
You need to make sure that it doesn't try to restart if it's received
a signal that the system's going down
I suppose the bash running the "loopmyprogram" script will get the kill
signal, as well and stop right away.
-Michael
On 01/14/2014 12:10 PM, Michael Van Canneyt wrote:
Whether you launch a script or an actual program is entirely irrelevant.
We are discussing Linux, not Windows. So we will get what we expect :-) .
-Michael
___
fpc-pascal maillist - fpc-pascal@list
On Tue, 14 Jan 2014, Michael Schnell wrote:
On 01/14/2014 11:52 AM, Michael Van Canneyt wrote:
Of course it will wait. A script always waits till a command exits.
I see. Thanks (silly me).
In your init.d script you need launch the above script (call it
loopmyprogram) in the usual manner, i
Michael Van Canneyt wrote:
Does it exit in a sufficiently-controlled state that you could simply
exec a new copy at the end of the finalization block? The available
parameters should be accessible in /proc.
No need to modify the program. You can simply script it as
#!/bin/bash
while [ 1 ]; d
In our previous episode, Sven Barth said:
>
> Maybe an overload could be added to load functions by ordinal on Windows
> and which simply returns Nil on other platforms.
I thought the index feature originated in win3.x and was mostly considered
deprecated by MS?
__
On 01/14/2014 11:52 AM, Michael Van Canneyt wrote:
Of course it will wait. A script always waits till a command exits.
I see. Thanks (silly me).
In your init.d script you need launch the above script (call it
loopmyprogram) in the usual manner, in the background.
Is there a more recommended "u
On Tue, 14 Jan 2014, Michael Schnell wrote:
On 01/14/2014 11:55 AM, Michael Van Canneyt wrote:
I had thought about introducing this when doing the implementation, but
decided against it.
Thanks for the warning.
You're welcome.
It also explains why I would go for the scripting solution. A
On 01/14/2014 11:55 AM, Michael Van Canneyt wrote:
I had thought about introducing this when doing the implementation,
but decided against it.
Thanks for the warning.
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.fr
On Tue, 14 Jan 2014, Michael Schnell wrote:
On 01/14/2014 11:35 AM, Tony Whyman wrote:
Michael,
This should be a classic Unix program with two separate parent and child
processes, where the child process runs your program and the parent is
responsible for monitoring the child and respawning
On Tue, 14 Jan 2014, Michael Schnell wrote:
On 01/14/2014 11:32 AM, Michael Van Canneyt wrote:
#!/bin/bash
while [ 1 ]; do
yourprogram youroptions
done
I feel this will start multiple parallel copies of the program and not wait
until the previous one dies.
Of course it will wait.
A sc
On 01/14/2014 11:35 AM, Tony Whyman wrote:
Michael,
This should be a classic Unix program with two separate parent and child
processes, where the child process runs your program and the parent is
responsible for monitoring the child and respawning it when it stops.
The basic algorithm of the par
On 01/14/2014 11:32 AM, Michael Van Canneyt wrote:
#!/bin/bash
while [ 1 ]; do
yourprogram youroptions
done
I feel this will start multiple parallel copies of the program and not
wait until the previous one dies.
Moreover I understand that this loop will never exit. Hence I can't use
it a
On 01/14/2014 11:26 AM, Mark Morgan Lloyd wrote:
Does it exit in a sufficiently-controlled state
Yep. If nothing completely unexpected happens, it writes a message in a
log file and cleanly exits. Of course there _might_ be memory leaks, an
unexpected kill signal or other queer stuff that co
Michael,
This should be a classic Unix program with two separate parent and child
processes, where the child process runs your program and the parent is
responsible for monitoring the child and respawning it when it stops.
The basic algorithm of the parent is:
Begin
...
daemon(0,0):
..
repe
On Tue, 14 Jan 2014, Mark Morgan Lloyd wrote:
Michael Schnell wrote:
Hi Linux Experts.
Since years I am running an fpc program as a kind of daemon on a PC Linux
server.
I simply defined a "respawn" line in /etc/inittab and with any start of the
server, the program happily automatically r
Michael Schnell wrote:
Hi Linux Experts.
Since years I am running an fpc program as a kind of daemon on a PC
Linux server.
I simply defined a "respawn" line in /etc/inittab and with any start of
the server, the program happily automatically runs as a daemon.
I would appreciate any idea on
On 10/01/2014 13:27, Reinier Olislagers wrote:
> Thanks to earlier help I got to build an ARM Linux cross compiler module
> in fpcup which even compiles fpcup itself (both using trunk and stable
> starting compiler):
> opt="-fPIC -dFPC_ARMHF"
> crossopt="-CpARMV6 -CaEABIHF -CfVFPV2"
>
> fpc -g -gl
Hi Linux Experts.
Since years I am running an fpc program as a kind of daemon on a PC
Linux server.
I simply defined a "respawn" line in /etc/inittab and with any start of
the server, the program happily automatically runs as a daemon.
Now I migrated the the PC Linux server to an ARM based
I have boiled down my problem to this democode. The problem is in the
begin line of set Direction. The sp gets moved to 0x0fff8f94 which is
unititialized Space before RAM.
The Reason is that the offset for the local var .Lj9 (.long -32840) is
plain wrong. It might be me doing something strange
Am 14.01.2014 00:12 schrieb "Ewald" :
>
>
> On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
>
>> The SoundTouch.dll uses index to call the procedures.
>>
>> Like that :
>> [Ordinal/Name Pointer]
>> [ 0] soundtouch_clear
>> [ 1] soundtouch_createInstance
>> [ 2] soundtouch_destr
36 matches
Mail list logo
