Am 14.01.2014 00:12 schrieb Ewald ew...@yellowcouch.org:
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]
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
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
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 -Tlinux
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 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
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):
..
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
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
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
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
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 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
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: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
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?
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 ];
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 -
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
Am 14.01.2014 12:04 schrieb Marco van de Voort mar...@stack.nl:
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
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.
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
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 ''...
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
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) :
Am 14.01.2014 14:02 schrieb Tomas Hajny xhaj...@hajny.biz:
On Tue, January 14, 2014 09:24, Sven Barth wrote:
Am 14.01.2014 00:12 schrieb Ewald ew...@yellowcouch.org:
On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
The SoundTouch.dll uses index to call the procedures.
.
.
No,
Am 14.01.2014 13:21 schrieb Fred van Stappen fi...@hotmail.com:
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
Am 14.01.2014 09:24 schrieb Sven Barth pascaldra...@googlemail.com:
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.
On Tue, 14 Jan 2014, Sven Barth wrote:
Am 14.01.2014 09:24 schrieb Sven Barth pascaldra...@googlemail.com:
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
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 -
@
Hinst, Michael, Tomas, Mark, Lukasz, Ewald, Marco, Sven and Waldo :
MANY, MANY THANKS.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
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.
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
33 matches
Mail list logo
