Opened by Echelon1010000 at 2005-07-08 12:34
User since
2005-06-29
18 Artikel
BenutzerIn
![[default_avatar]](/battie/theme/default/default_avatar.gif)
2005-06-29
18 Artikel
BenutzerIn
Hi
Im Moment ist es so das der Rückgabewert eine Fehlermeldung enthält wenn er <> 1 ist. In gewissem Sinne weiss ich das also schon.
Basierend auf deinem Vorschlag könnte ich mir sowas Vorstellen:
Caller kenne ich schon. Ich verwende es in der Funktion getsocket(); um jedem aufrufenden Modul den passenden Socket zuzuordnen. Allerdings ist, laut Doku, die Funkion nur bedingt aussagefähig. Soweit ich weiss soll man sich nicht allzusehr darauf verlassen und mehr als 2 oder 3 Sprünge zurückgehen. (In meinem Fall muessen zw. 5 und 6 Sprünge zurückverfolgt werden: Modul -> Sub im Modul in der der Childprozess läuft -> Aufruf der Sub die mit dem Display kommuniziert -> Aufruf der Sub suck(); )
Der Ausschnitt asu der Doku den ich meine ist dieser:
Daher schrecke ich da ein wenig vor zurück. Abgesehen davon das dieses Gerüst zusammen fällt wenn sich die Anzahl der Subs im Modul verändert. Wenn ich dort eine Sub einbaue die den Screen erzeugt "setupscreens();" und auch mit dem Display kommunizieren will stimmt die Anzahl der Funktionsaufrufe nicht mehr die vor der Sub liegen die den Subnamen ermitteln will.
Gruss, Echelon
Im Moment ist es so das der Rückgabewert eine Fehlermeldung enthält wenn er <> 1 ist. In gewissem Sinne weiss ich das also schon.
Basierend auf deinem Vorschlag könnte ich mir sowas Vorstellen:
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
sub addstring
{
...
...
...
my $answer=suck($socket);
if ( $answer == 1 ) { return 1;}
if ( $answer == 2 ) {print "Modul $modul hat versucht auf widget $widgetname zuzugreifen, dieses Widget existiert nicht";return 0; }
if ( $answer == 3 ) { print "Es wurde durch Modul $modulname ein falscher Parameter für widget $widgetname übergeben";return 0; }
...
...
...
}
sub suck
{
...
...
...
if ( index($message,"listen") >=0 ) { debug ("Discarded listen message ($message)");goto SUCKLOOP;}
if ( index($message,"ignore") >=0 ) { debug ("Discarded ignore message ($message)");goto SUCKLOOP;}
if ( index($message,"connect") >=0 ) { debug ("successfully registered as a client ($message)");return 1;}
if ( index($message,"huh?") >=0 )
{
debug("error ($message)");
if ( $message = "huh? unknown widget id" ){return 2;}
if ( $message = "huh? incorrect parameter" ){return 3;}
....
....
}
if ( index($message,"success") >=0 ) { debug("success");return 1;}
}
Caller kenne ich schon. Ich verwende es in der Funktion getsocket(); um jedem aufrufenden Modul den passenden Socket zuzuordnen. Allerdings ist, laut Doku, die Funkion nur bedingt aussagefähig. Soweit ich weiss soll man sich nicht allzusehr darauf verlassen und mehr als 2 oder 3 Sprünge zurückgehen. (In meinem Fall muessen zw. 5 und 6 Sprünge zurückverfolgt werden: Modul -> Sub im Modul in der der Childprozess läuft -> Aufruf der Sub die mit dem Display kommuniziert -> Aufruf der Sub suck(); )
Der Ausschnitt asu der Doku den ich meine ist dieser:
QuoteBe aware that the optimizer might have optimized call frames
away before "caller" had a chance to get the information. That
means that caller(N) might not return information about the
call frame you expect it do, for "N > 1". In particular,
@DB::args might have information from the previous time
"caller" was called.
Daher schrecke ich da ein wenig vor zurück. Abgesehen davon das dieses Gerüst zusammen fällt wenn sich die Anzahl der Subs im Modul verändert. Wenn ich dort eine Sub einbaue die den Screen erzeugt "setupscreens();" und auch mit dem Display kommunizieren will stimmt die Anzahl der Funktionsaufrufe nicht mehr die vor der Sub liegen die den Subnamen ermitteln will.
Gruss, Echelon