Re: expr complaint on FreeBSD for MinGW cross
* Ralf Wildenhues wrote on Sat, Apr 19, 2008 at 01:56:59AM CEST: Ouch. ETOOLATE. Of course $name is used, in libname_spec for example. Please ignore this, I'll post an updated patch. OK to apply? Thanks, Ralf 2008-04-19 Ralf Wildenhues [EMAIL PROTECTED] Fix nonportable use of expr. * libltdl/config/ltmain.m4sh (func_mode_link) Transforming deplibs into only shared deplibs: Fix expr portability issues, noted on FreeBSD. While at it, simplify and avoid forking. Report by Bob Friesenhahn. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 8c5c45c..5018de8 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -5558,9 +5558,10 @@ EOF if $LTCC $LTCFLAGS -o conftest conftest.c $deplibs; then ldd_output=`ldd conftest` for i in $deplibs; do - name=`expr $i : '-l\(.*\)'` - # If $name is empty we are operating on a -L argument. - if test $name != test $name != 0; then + case $i in + -l*) + func_stripname -l '' $i + name=$func_stripname_result if test X$allow_libtool_libs_with_static_runtimes = Xyes ; then case $predeps $postdeps in * $i *) @@ -5587,17 +5588,20 @@ EOF $ECHO *** its dynamic dependency list that programs get resolved with at runtime. fi fi - else + ;; + *) newdeplibs=$newdeplibs $i - fi + ;; + esac done else # Error occurred in the first compile. Let's try to salvage # the situation: Compile a separate program for each library. for i in $deplibs; do - name=`expr $i : '-l\(.*\)'` - # If $name is empty we are operating on a -L argument. - if test $name != test $name != 0; then + case $i in + -l*) + func_stripname -l '' $i + name=$func_stripname_result $opt_dry_run || $RM conftest if $LTCC $LTCFLAGS -o conftest conftest.c $i; then ldd_output=`ldd conftest` @@ -5635,9 +5639,11 @@ EOF $ECHO *** library that it depends on before this library will be fully $ECHO *** functional. Installing it before continuing would be even better. fi - else + ;; + *) newdeplibs=$newdeplibs $i - fi + ;; + esac done fi ;; @@ -5645,9 +5651,10 @@ EOF set dummy $deplibs_check_method; shift file_magic_regex=`expr $deplibs_check_method : $1 \(.*\)` for a_deplib in $deplibs; do - name=`expr $a_deplib : '-l\(.*\)'` - # If $name is empty we are operating on a -L argument. - if test $name != test $name != 0; then + case $a_deplib in + -l*) + func_stripname -l '' $a_deplib + name=$func_stripname_result if test X$allow_libtool_libs_with_static_runtimes = Xyes ; then case $predeps $postdeps in * $a_deplib *) @@ -5704,19 +5711,22 @@ EOF $ECHO *** using a file magic. Last file checked: $potlib fi fi - else + ;; + *) # Add a -L argument. newdeplibs=$newdeplibs $a_deplib - fi + ;; + esac done # Gone through all deplibs. ;; match_pattern*) set dummy $deplibs_check_method; shift match_pattern_regex=`expr $deplibs_check_method : $1 \(.*\)` for a_deplib in $deplibs; do - name=`expr $a_deplib : '-l\(.*\)'` - # If $name is empty we are operating on a -L argument. - if test -n $name test $name != 0; then + case $a_deplib in + -l*) + func_stripname -l '' $a_deplib + name=$func_stripname_result if test X$allow_libtool_libs_with_static_runtimes = Xyes ; then case $predeps $postdeps in * $a_deplib *) @@ -5755,10 +5765,12 @@ EOF $ECHO *** using a regex pattern. Last file checked: $potlib fi fi - else + ;; + *) # Add a -L argument. newdeplibs=$newdeplibs $a_deplib - fi + ;; + esac done # Gone through all deplibs. ;; none | unknown | *)
Re: func_arith and func_len
On Sat, 19 Apr 2008, Ralf Wildenhues wrote: Let's reuse at_func_arith from Autotest, to redo one of the link mode speedups that fell under the cracks a couple of years ago. IIRC somebody else suggested this recently, but I don't remember who. Please speak up so I can put your name in the ChangeLog entry. Roland Mainz [EMAIL PROTECTED] (OpenSolaris/Ksh93 guy) is the suitable party to blame. Note that for pre-Posix shells, the number of forks doubles in those loops (but the quadratic counting is not present there either); for practical cases that will lead to a slow-down with those shells. OK to apply? For these kind of dramatic improvements, I think that the users should be paying a much higher fee. I propose that the fee be increased to 35% more than they are paying today. I do not see anything wrong with the patch. Please apply it. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Patch for cygwin: autoupdate and objdump
Charles Wilson wrote: Not only that, but this may fix another possible bug on Linux ELF systems, as there is a test on that platform (line 2461 after the patch) which uses OBJDUMP, which I don't see where it would have been defined. Ah...found the OTHER other thread where the OBJDUMP issue was mentioned: http://lists.gnu.org/archive/html/libtool/2008-04/msg00099.html which was again a missing win32-dll. But, for non-data-exporting, non-cross-compiled, you didn't actually need AC_LIBTOOL_WIN32_DLL in libtool-1.5... -- Chuck
Re: expr complaint on FreeBSD for MinGW cross
On Sat, 19 Apr 2008, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Sat, Apr 19, 2008 at 01:56:59AM CEST: Ouch. ETOOLATE. Of course $name is used, in libname_spec for example. Please ignore this, I'll post an updated patch. OK to apply? While I have not tested this patch, it looks ok to apply to me. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: func_arith and func_len
[ http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00096.html ]
Hello Bob, Roland,
* Bob Friesenhahn wrote on Sat, Apr 19, 2008 at 05:13:13PM CEST:
On Sat, 19 Apr 2008, Ralf Wildenhues wrote:
Let's reuse at_func_arith from Autotest, to redo one of the link mode
speedups that fell under the cracks a couple of years ago.
IIRC somebody else suggested this recently, but I don't remember who.
Please speak up so I can put your name in the ChangeLog entry.
Roland Mainz [EMAIL PROTECTED] (OpenSolaris/Ksh93 guy) is the
suitable party to blame.
Thanks, Cc:ed.
OK to apply?
I do not see anything wrong with the patch. Please apply it.
Thanks for the quick review. Applied and pushed, I've put Roland in
THANKS.
Cheers,
Ralf
2008-04-19 Ralf Wildenhues [EMAIL PROTECTED]
Exploit shell arithmetic expansion and ${#var}.
* libltdl/m4/libtool.m4 (_LT_CHECK_SHELL_FEATURES): Also check
for arithmetic expansion, and ${#var}.
(_LT_PROG_XSI_SHELLFNS): Define func_arith and func_len
accordingly, falling back on 'expr'. Note that the argument to
func_len may not start with a hyphen. In the pre-Posix
fallback, take care not to rely on the exit status of the
variable assignment (not portable), but set the length to
$max_cmd_len instead.
* libltdl/config/ltmain.m4sh (func_mode_link): Use func_arith
and func_len throughout for integer arithmetic, fixing
quadratical amount of counting for reloadable object and
piecewise archive linking. Change all comparisons with
max_cmd_len to test for smaller, non-equal length.
* THANKS: Update.
Suggested by Roland Mainz.
Re: expr complaint on FreeBSD for MinGW cross
* Bob Friesenhahn wrote on Sat, Apr 19, 2008 at 06:13:58PM CEST: On Sat, 19 Apr 2008, Ralf Wildenhues wrote: OK to apply? While I have not tested this patch, it looks ok to apply to me. Thanks, pushed as well. Cheers, Ralf
Re: add cegcc support
Here is another patch. It changes cegcc to cegcc* and *-cegcc* to
*-*-cegcc*
Indeed, the cegcc compiler can have in the future another name with a
suffix, according to cegcc developpers.
A minor nit:
--- libltdl/config/ltmain.m4sh 11 Apr 2008 17:21:55 - 1.106
+++ libltdl/config/ltmain.m4sh 19 Apr 2008 16:33:59 -
[...]
@@ -1714,7 +1714,7 @@
# Do a test to see if this is really a libtool program.
case $host in
- *cygwin*|*mingw*)
+ *cygwin* | *mingw*)
Is the omission of cegcc here on purpose? If so, then let's drop this
whitespace-only change.
It is on purpose. I've removed the spaces in the attached patch.
regards
Vincent Torri? libtool_cegcc.diff
? libtool_cegcc2.diff
? lt.diff
? patch_libtool_cvs.diff
? tests/testsuite.dir
Index: libltdl/config/ltmain.m4sh
===
RCS file: /sources/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.106
diff -u -r1.106 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 11 Apr 2008 17:21:55 - 1.106
+++ libltdl/config/ltmain.m4sh 19 Apr 2008 17:22:22 -
@@ -363,7 +363,7 @@
case $host in
-*cygwin* | *mingw* | *pw32*)
+*cygwin* | *mingw* | *pw32* | *cegcc*)
# don't eliminate duplications in $postdeps and $predeps
opt_duplicate_compiler_generated_deps=:
;;
@@ -836,7 +836,7 @@
# On Cygwin there's no real PIC flag so we must build both object types
case $host_os in
-cygwin* | mingw* | pw32* | os2*)
+cygwin* | mingw* | pw32* | os2* | cegcc*)
pic_mode=default
;;
esac
@@ -1608,7 +1608,7 @@
'exit $?'
tstripme=$stripme
case $host_os in
- cygwin* | mingw* | pw32*)
+ cygwin* | mingw* | pw32* | cegcc*)
case $realname in
*.dll.a)
tstripme=
@@ -1920,7 +1920,7 @@
$RM $export_symbols
eval ${SED} -n -e '/^: @PROGRAM@ $/d' -e 's/^.* \(.*\)$/\1/p'
' $nlist $export_symbols'
case $host in
- *cygwin* | *mingw* )
+ *cygwin* | *mingw* | *cegcc*)
eval echo EXPORTS ' $output_objdir/$outputname.def'
eval 'cat $export_symbols
$output_objdir/$outputname.def'
;;
@@ -1932,7 +1932,7 @@
eval '$GREP -f $output_objdir/$outputname.exp $nlist
$nlistT'
eval '$MV $nlistT $nlist'
case $host in
- *cygwin | *mingw* )
+ *cygwin | *mingw* | *cegcc*)
eval echo EXPORTS ' $output_objdir/$outputname.def'
eval 'cat $nlist $output_objdir/$outputname.def'
;;
@@ -1988,7 +1988,7 @@
} lt_dlsymlist;
case $host in
- *cygwin* | *mingw* )
+ *cygwin* | *mingw* | *cegcc*)
$ECHO $output_objdir/$my_dlsyms \
/* DATA imports from DLLs on WIN32 con't be const, because
runtime relocations are performed -- see ld's documentation
@@ -2074,7 +2074,7 @@
# Transform the symbol file into the correct name.
symfileobj=$output_objdir/${my_outputname}S.$objext
case $host in
- *cygwin* | *mingw* )
+ *cygwin* | *mingw* | *cegcc*)
if test -f $output_objdir/$my_outputname.def; then
compile_command=`$ECHO X$compile_command | $Xsed -e [EMAIL
PROTECTED]@%$output_objdir/$my_outputname.def $symfileobj%`
finalize_command=`$ECHO X$finalize_command | $Xsed -e [EMAIL
PROTECTED]@%$output_objdir/$my_outputname.def $symfileobj%`
@@ -2449,7 +2449,7 @@
case $host in
# Backslashes separate directories on plain windows
- *-*-mingw | *-*-os2*)
+ *-*-mingw | *-*-os2* | *-*-cegcc*)
$ECHO \
exec \\$progdir\$program\ \${1+\[EMAIL PROTECTED]}
@@ -3076,7 +3076,7 @@
{
$opt_debug
case $host in
-*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-cegcc*)
# It is impossible to link a dll without this setting, and
# we shouldn't force the makefile maintainer to figure out
# which system we are compiling for in order to pass an extra
@@ -3537,7 +3537,7 @@
;;
esac
case $host in
- *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+ *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-cegcc*)
testbindir=`$ECHO X$dir | $Xsed -e 's*/lib$*/bin*'`
case :$dllsearchpath: in
*:$dir:*) ;;
@@ -3555,7 +3555,7 @@
-l*)
if test X$arg = X-lc || test X$arg = X-lm; then
case $host in
- *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-beos*)
+ *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-beos* | *-*-cegcc*)
# These systems don't actually have a C or math library (as such)
continue
;;
@@ -3632,7 +3632,7 @@
-no-install)
case $host in
-
Re: func_arith and func_len
Hello Roland,
* Roland Mainz wrote on Sat, Apr 19, 2008 at 11:46:02PM CEST:
On 4/19/08, Ralf Wildenhues [EMAIL PROTECTED] wrote:
[ http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00096.html
]
[snip]
2008-04-19 Ralf Wildenhues [EMAIL PROTECTED]
Exploit shell arithmetic expansion and ${#var}.
[...]
Suggested by Roland Mainz.
Erm... thanks! ... :-)
... is it possible to see the diff -u for the change and a shell
script code sample how the generated shell code may look like ?
Yes. The diff -u is in the link that I quoted at the beginning.
The
part where I am curently worrying is something like (( foo=$foo+5))
vs. (( foo=foo+5 )) - the first firm is wrong because it forces the
shell to convert the value for foo into a string and back after
expansion while the 2nd form avoids this mess (for integer operations
this is just a performance issue, for floating-point math the first
form leads to wrong results because the conversion to a string will
normally cause rounding errors due the base2base10---base2
conversion
Sorry, but: first, there is no floating point in either Libtool, nor
Posix shell semantics. Second, if you can prove to me (by posting
timing comparisons) that conversion from integer to string or vice
versa, has *any* performance impact whatsoever on Libtool, I'll gladly
send lots of beer your way. I mean hey, we still fork quite a bit, and
you can probably solve a cheap differential equation during the time
that one fork takes even on sane systems like Linux.
No really, nothing of that sort of questions even remotely applies to
Libtool.
Cheers,
Ralf
Re: func_arith and func_len
On Sun, 20 Apr 2008, Ralf Wildenhues wrote: Sorry, but: first, there is no floating point in either Libtool, nor Posix shell semantics. Second, if you can prove to me (by posting timing comparisons) that conversion from integer to string or vice versa, has *any* performance impact whatsoever on Libtool, I'll gladly send lots of beer your way. I mean hey, we still fork quite a bit, and While for our purposes it is indeed unlikely that we can measure the difference, it seems that the code should use the most correct implementation if using it requires minimal effort. If all shells supporting this math syntax also support the native math types (which they likely do since this syntax comes from old ksh), then is there a reason why we would not prefer the native syntax for math if we are doing math? Is there a ripple effect? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: func_arith and func_len
* Bob Friesenhahn wrote on Sun, Apr 20, 2008 at 02:42:00AM CEST: On Sun, 20 Apr 2008, Ralf Wildenhues wrote: Sorry, but: first, there is no floating point in either Libtool, nor Posix shell semantics. Second, if you can prove to me (by posting timing comparisons) that conversion from integer to string or vice versa, has *any* performance impact whatsoever on Libtool, I'll gladly send lots of beer your way. I mean hey, we still fork quite a bit, and While for our purposes it is indeed unlikely that we can measure the difference, it seems that the code should use the most correct implementation if using it requires minimal effort. There is no more or less correct in this case. If all shells supporting this math syntax also support the native math types (which they likely do since this syntax comes from old ksh), then is there a reason why we would not prefer the native syntax for math if we are doing math? Is there a ripple effect? Yes. The factoring into a shell function which supports Posix syntax and a shell function which does the same but using expr is a lot simpler. Apart from all this reasoning, I doubt that the shell *has* to convert integers with (($x)); it looks like that would be a quality of implementation issue. Of course, Libtool doesn't used typed variables at all, they are not Posix, and I guess factorizing that for ksh especially is not worth the effort. But hey, try it out and prove me wrong with your timings. Cheers, Ralf
Re: func_arith and func_len
On 4/20/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Roland Mainz wrote on Sat, Apr 19, 2008 at 11:46:02PM CEST: On 4/19/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: [ http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00096.html ] [snip] Erm... thanks! ... :-) ... is it possible to see the diff -u for the change and a shell script code sample how the generated shell code may look like ? Yes. The diff -u is in the link that I quoted at the beginning. Oh.. I missed that... sorry... ;-( ... Thanks! :-) The part where I am curently worrying is something like (( foo=$foo+5)) vs. (( foo=foo+5 )) - the first firm is wrong because it forces the shell to convert the value for foo into a string and back after expansion while the 2nd form avoids this mess (for integer operations this is just a performance issue, for floating-point math the first form leads to wrong results because the conversion to a string will normally cause rounding errors due the base2base10---base2 conversion Sorry, but: first, there is no floating point in either Libtool, nor Posix shell semantics. No, but the general issue applies to integer math, too - and that is part of the POSIX shell spec and supported by ksh88, ksh93, bash etc. And the floating-point thing is now on the ToDo list for the next revision of the standard... Second, if you can prove to me (by posting timing comparisons) that conversion from integer to string or vice versa, Here come the requested numbers: -- snip -- $ timex ksh93 -c 'integer i sum=0 ; for (( i=0 ; i 10 ; i++ )) ; do (( sum=sum+1 )) ; done ; print $sum' 10 real 3.89 user 3.81 sys 0.02 $ timex ksh93 -c 'integer i sum=0 ; for (( i=0 ; i 10 ; i++ )) ; do (( sum=$sum+1 )) ; done ; print $sum' 10 real 18.70 user 18.52 sys 0.03 -- snip -- .. or short: (( sum=$sum+1 )) is at least five times slower than (( sum=sum+1 )) has *any* performance impact whatsoever on Libtool, I'll gladly send lots of beer your way. Erm... I don't have a good way to benchmark libtool... all machines I have access to are either heavily overtaxed with swapping or shared between multiple users (an option may be to use the realtime scheduler class on Solaris for benchmarking but that requires root access... ;-/ ). I mean hey, we still fork quite a bit, and you can probably solve a cheap differential equation during the time that one fork takes even on sane systems like Linux. Right... technically |fork()| is one problem... and |exec()| the other - each |exec()| call must make crosscalls to all CPUs (belonging to that OS image) to tear-down the address space being used... and that becomes time-consuming on machines with 256 CPU strands (like the four-socket Niagara 2+ machines (and don't ask how horrible this will be on the machines with 2048 CPU strands (see http://www.theregister.co.uk/2007/07/26/sun_2048_thread_niagara/))) ... ;-( ... but the |fork()|+|exec()| thing in Solaris's libtool 1.5.x is now mainly under control on our side ; ksh93 has many common commands built-in (e.g. basename, dirname, printf, mkdir, rmdir, mkfifo etc.) and using them greatly reduces the number of |fork()|+|+|exec()| done. Another group is doing benchmarking of the patch but AFAIK it looks very good right now... BTW: below is the Solaris patch for libtool 1.5.x I've used to improve the performace: -- snip -- diff -N -r -u original/usr/src/cmd/libtool/libtool_force_ksh_print_builtin.diff usr/src/cmd/libtool/libtool_force_ksh_print_builtin.diff --- original/usr/src/cmd/libtool/libtool_force_ksh_print_builtin.diff 1970-01-01 01:00:00.0 +0100 +++ usr/src/cmd/libtool/libtool_force_ksh_print_builtin.diff 2008-04-16 23:28:29.04266 +0200 @@ -0,0 +1,50 @@ +diff -u libtool-1.5.22/libtool.m4 libtool-1.5.22/libtool.m4 +--- libtool-1.5.22/libtool.m4 2005-12-18 22:53:17.0 +0100 libtool-1.5.22/libtool.m4 2008-04-16 23:27:06.989694000 +0200 +@@ -390,7 +390,7 @@ + done + IFS=$lt_save_ifs + +- if test X$echo = Xecho; then ++ if true ; then + # We didn't find a better echo, so look for alternatives. + if test X`(print -r '\t') 2/dev/null` = 'X\t' +echo_testing_string=`(print -r $echo_test_string) 2/dev/null` +@@ -4229,6 +4229,38 @@ + # configuration script generated by Autoconf, you may include it under + # the same distribution terms that you use for the rest of that program. + ++builtin \ ++ basename \ ++ cat \ ++ chgrp \ ++ chmod \ ++ chown \ ++ cmp \ ++ cp \ ++ cut \ ++ date \ ++ dirname \ ++ expr \ ++ fold \ ++ head \ ++ id \ ++ join \ ++ ln \ ++ logname \ ++ mkdir \ ++ mkfifo \ ++ mv \ ++ paste \ ++ rev \ ++ rm \ ++ rmdir \ ++ tail \ ++ tee \ ++ tty \ ++ uname \ ++ uniq \ ++ wc ++ + # A sed program that does not
Re: func_arith and func_len
* Roland Mainz wrote on Sun, Apr 20, 2008 at 03:03:24AM CEST: On 4/20/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: Second, if you can prove to me (by posting timing comparisons) that conversion from integer to string or vice versa, Here come the requested numbers: -- snip -- $ timex ksh93 -c 'integer i sum=0 ; for (( i=0 ; i 10 ; i++ )) ; do (( sum=sum+1 )) ; done ; print $sum' 10 Libtool does at most C + 2 * O additions, with O being the number of objects, and C a small constant, 5 or so. And that's only in link mode. So, ... real 3.89 $ timex ksh93 -c 'integer i sum=0 ; for (( i=0 ; i 10 ; i++ )) ; do (( sum=$sum+1 )) ; done ; print $sum' 10 real 18.70 we're talking about 0.5 seconds for the largest link I've ever seen, comprising 3000 objects. I'm honest I'm surprised it should be that much, but I don't think it will be noticeable compared with the run time of ld and ar. FWIW, on my laptop the above loops take 0.3 and 0.6 seconds, respectively (ksh93 on GNU/Linux). has *any* performance impact whatsoever on Libtool, I'll gladly send lots of beer your way. Erm... I don't have a good way to benchmark libtool... all machines I have access to are either heavily overtaxed with swapping or shared between multiple users (an option may be to use the realtime scheduler class on Solaris for benchmarking but that requires root access... ;-/ ). If you're serious about this, getting a shell account to do benchmarking is not a problem. Besides, looking at process time is useful even if it's not correlated well with real time. BTW: below is the Solaris patch for libtool 1.5.x I've used to improve the performace: Thanks for the patch. Chunk one makes sure we use print -r for ksh-based shells because otherwise the automake stuff will attempt to use /usr/ucb/echo (which requires a |fork()|+|exec()|) Ah, prefering 'print -r' over /usr/ucb/echo is a good idea. Will look into a patch to do this properly. ; the 2nd chunk enables lots of builtins present in ksh93 version 's+' (which saves lots of fork()|+|exec()| calls, too) ... You might have posted before, but can you please show again how much just the builtin stuff saves you in practice? It would be most interesting to see numbers comparing the current development tree against the current development tree with your patch added (but with 'print -r' used in both cases). 1.5.x is not a good comparison, we're not developing that any more. Thanks, Ralf
