unuse module;: any workaround (Seite 2) (Allgemeines zu Perl)

[thread]7364[/thread]

unuse module;: any workaround (Seite 2)

Leser: 2

lichtkind

2005-10-18 14:28

User since
2004-03-22
5681 Artikel
ModeratorIn + EditorIn

danke cremator aber soweit ich den code verstehe macht er das packet "sauber" aber er entfernt es nicht

pq: das hab ich beachtet wahrscheinlich aber was anderes durcheinander gebracht.\n\n

Tutorien in der Wiki, mein zeug:
kephra, baumhaus, garten, gezwitscher

Es beginnt immer mit einer Entscheidung.

Cremator

2005-10-18 23:01

User since
2003-11-26
97 Artikel
BenutzerIn
[default_avatar]

Ebent. :)

Erst "säubern" und dann den Modulnamen aus dem INC-Hash löschen. So kannst Du sicher sein, das keine Reste von der zuvor geladenen Version übrig sind, da der Namespace dann auch leer ist.

Wobei Du beim Löschen die '::' im Modulnamen durch '/' ersetzen und das .pm anhaengen musst, aber das hast Du in perlvar wahrscheinlich schon selbst mitbekommen.

lichtkind

2005-10-23 03:57

User since
2004-03-22
5681 Artikel
ModeratorIn + EditorIn

ich hab mir so beholfen, folgendes ist gut genug für mich:

Code (perl): (dl )

sub GetPceVersion{
 my $release = shift;
    die "no release name given SourceControl::GetPceVersion" unless $release;
    die "unknown release  name given SourceControl::GetPceVersion" unless defined $releases{$release};
 my $basepath = $releases{$release}{'path'};
    $basepath .= "/" if substr($basepath,-1) ne "/";
 my $content = " push \@INC, '$basepath'.\$_ for(";
    $content .= "'$_'," for (@inc_pathes);
    chop $content;
    $content .= ");\n require pce; \n \$pce::VERSION;";
 my $temp_script_name = 'GetVersion'. (int rand 1000) .'.pl';
    open F, ">$temp_script_name";
    print F $content;
    close F;
 my @tmpINC = @INC;
 my %tmpINC = %INC;
    $releases{$release}{'version'} = do $temp_script_name;
    %INC = %tmpINC;
    @INC = @tmpINC;
    unlink $temp_script_name;
    return $releases{$release}{'version'};
}

Tutorien in der Wiki, mein zeug:
kephra, baumhaus, garten, gezwitscher

Es beginnt immer mit einer Entscheidung.

betterworld

2005-10-23 12:29

User since
2003-08-21
2613 Artikel
ModeratorIn

user image

Ueberpruefst Du nicht die Rueckgabewerte von open und unlink?

Lieblingsmodule: CPAN:

IPC::System::Simple, CPAN:

Path::Class

murphy

2005-10-23 18:10

User since
2004-07-19
1776 Artikel
HausmeisterIn

[quote=Cremator,18.10.2005, 21:01][...]
Erst "säubern" und dann den Modulnamen aus dem INC-Hash löschen. So kannst Du sicher sein, das keine Reste von der zuvor geladenen Version übrig sind, da der Namespace dann auch leer ist.
[...][/quote]
Aber Vorsicht: Das herumspielen am Namensraum kann mit unerwünschten Nebenwirkungen verbunden sein!

Perl führt nicht für jeden Subroutinenaufruf eine volle Suche im Namensraum aus, sondern hat da irgendeinen schlauen Puffermechanismus. Wenn man also ein Modul auf die besagte Art und Weise "entlädt", dann kann es passieren, dass Code, der das Modul benutzt, und bereits mindestens einmal ausgeführt wurde, nicht mehr funktioniert, selbst wenn man das entladene Modul erneut lädt.

When C++ is your hammer, every problem looks like your thumb.

ptk

2005-10-24 00:20

User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]

[quote=betterworld,23.10.2005, 10:29]Ueberpruefst Du nicht die Rueckgabewerte von open und unlink?[/quote]
Vielleicht benutzt er "use Fatal"

ptk

2005-10-24 00:33

User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]

[quote=murphy,23.10.2005, 16:10][quote=Cremator,18.10.2005, 21:01][...]
Erst "säubern" und dann den Modulnamen aus dem INC-Hash löschen. So kannst Du sicher sein, das keine Reste von der zuvor geladenen Version übrig sind, da der Namespace dann auch leer ist.
[...][/quote]
Aber Vorsicht: Das herumspielen am Namensraum kann mit unerwünschten Nebenwirkungen verbunden sein!

Perl führt nicht für jeden Subroutinenaufruf eine volle Suche im Namensraum aus, sondern hat da irgendeinen schlauen Puffermechanismus. Wenn man also ein Modul auf die besagte Art und Weise "entlädt", dann kann es passieren, dass Code, der das Modul benutzt, und bereits mindestens einmal ausgeführt wurde, nicht mehr funktioniert, selbst wenn man das entladene Modul erneut lädt.[/quote]
Bei normalen Subroutinen ist mir kein "Puffermechanismus" bekannt. Der folgende Code funktioniert wie erwartet:

Code: (dl )

sub test {
    warn "Alter Test!";
}
test();
eval q{
sub test {
    warn "Neuer Test!";
}
};
test();

Die auftretende Warnung kann man ausschalten (no warnings "redefine", wenn ich mich nicht irre).

Probleme kann es geben, wenn man Module wie "autouse" verwendet. Auch kann ich mir gut vorstellen, dass der AutoLoader mit nachladen nicht gut zurechtkommt. Und überall dort, wo mit Funktionsreferenzen gearbeitet wird, muss man vorsichtig sein. In Tk-Code schreibt man z.B. oft:

Code: (dl )

$mw->Button(-command => \&machwas)->pack;

Wenn jetzt machwas() umdefiniert wird, dann zeigt die Referenz noch immer auf die alte Funktion. Um dieses Problem zu umgehen, kann man stattdessen schreiben:

Code: (dl )

$mw->Button(-command => sub { machwas() })->pack;

Was zwar ein paar Mikrosekunden langsamer ist, aber das fällt bei einem Klick nicht auf.

"perldoc perlobj" sagt übrigens zum Methodencache:

Code: (dl )

1
2
3

If a missing method is found in a base class, it is cached in the cur-
       rent class for efficiency.  Changing @ISA or defining new subroutines
       invalidates the cache and causes Perl to do the lookup again.

Also auch hier kein Problem.

murphy

2005-10-24 05:14

User since
2004-07-19
1776 Artikel
HausmeisterIn

Hmm, ich muss zugeben, auf Anhieb kann ich auch kein minimalistisches Beispiel ohne Referenzen konstruieren, dass ein "Cacheproblem" hätte.

Ich habe allerdings folgendes in perldoc Symbol gefunden:
"[...] Since perl, for performance reasons, does not perform a symbol table lookup each time a function is called or a global variable is accessed, some code that has already been loaded and that makes use of symbols in package "Foo" may stop working after you delete "Foo", even if you reload the "Foo" module afterwards."

Also sollte man es im Zweifelsfalle vielleicht nicht darauf ankommen lassen...

When C++ is your hammer, every problem looks like your thumb.

ptk

2005-10-25 01:40

User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]

Bei den Perl5-Porters habe ich den passenden Thread gefunden: http://groups.google.com/group....81ac84b.
Dass ich auf dieses Problem nicht gestoßen bin, liegt wohl daran, dass ich nicht die Package komplett lösche (einschließlich "Placeholder"), sondern einfach nur überschreibe.

murphy

2005-10-25 03:02

User since
2004-07-19
1776 Artikel
HausmeisterIn

Ah! Das erklärt alles -- danke für den Link.

When C++ is your hammer, every problem looks like your thumb.

View all threads created 2005-10-17 23:23.