script und module zusammenfassen?

Ich habe einige selbstgeschriebene Scripte, die wiederum
selbstgeschriebene Module mittels use importieren. Das funktioniert bei
mir alles bestens, weil die Module in @INC stehen.

Jetzt moechte ich diese Programme an Kollegen weitergehen, die von Perl
gar nichts und von UNIX sehr wenig wissen. Denen zu erklaeren, was sie wie
wo installieren muessen ist sehr schwierig.

Ich wuerden daher denen gerne Script und Modul zusammen in einem File
schicken.

Bisher mach ich von Hand:

cat script module1 module2 ... >script_standalone
$EDITOR script_standalone
(use, package und Exporter Anweisungen auskommentieren)

Das muss doch auch eleganter,einfacher gehen?

--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Moritz Lenz wrote:

> > Ich wuerden daher denen gerne Script und Modul zusammen in einem File
> > schicken.
>
> Z.B. in einem .tar.gz, das sie entpacken

Schon zu kompliziert. Das kriegen die wenigsten hin.


> 'perl Makefile.PL; make; sudo make install' ausführen und gut ist?

root-Rechte haben sie schon gleich gar nicht. Das sind USER :-)


> Wenn die Kollegen alle die selbe Distribution benutzen

Distribution?! Die benutzen noch nicht mal alle dasselbe UNIX!

Nein, es muss ein file sein, der allen Code enthaelt. Alles andere ist
VIEL zu kompliziert.


--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Hallo,

On 11.10.2007 17:53, Ulli Horlacher wrote:

> Das muss doch auch eleganter,einfacher gehen?

wie wär's mit

Grüße,

-andreas

Re: script und module zusammenfassen?

Ulli Horlacher:
> cat script module1 module2 ... >script_standalone
> $EDITOR script_standalone
> (use, package und Exporter Anweisungen auskommentieren)

Vorsicht! "package" entfernen kann problematisch sein, wenn dein
Hauptcode und ein Modul denselben Namen für eine Variable oder
Funktion verwenden. Ohne "package" wird der gesamte Code in
den "main" Namensraum kompiliert. Das kann dazuführen, dass
unabsichtlich mehrfach dieselbe globale Variable angesprochen und
dadurch überschrieben wird.

> Das muss doch auch eleganter,einfacher gehen?

Die Frage ist, warum du selber eigene Module verwendest und
nicht gleich den ganzen Code in eine Datei packst?

Wie sollen deine Benutzer übrigens das Skript aufrufen?

LG, Ferry
--

Re: script und module zusammenfassen?

Andreas Thul wrote:
>
> Hallo,
>
> On 11.10.2007 17:53, Ulli Horlacher wrote:
>
> > Das muss doch auch eleganter,einfacher gehen?
>
> wie wär's mit

Das generiert executables, was fuer mich voellig unbrauchbar ist. Meine
Ziel-User haben andere Betriebsysteme und andere Hardware als ich.

Ich will nur Hauptprogramm und Modul in ein File zusammenpacken und das
ohne viel Aufwand.


--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Ferry Bolhar wrote:

> Ulli Horlacher:
> > cat script module1 module2 ... >script_standalone
> > $EDITOR script_standalone
> > (use, package und Exporter Anweisungen auskommentieren)
>
> Vorsicht! "package" entfernen kann problematisch sein, wenn dein
> Hauptcode und ein Modul denselben Namen für eine Variable oder
> Funktion verwenden.

Ja, das ist mir klar. Darauf achte ich schon. Deshalb such ich ja was, das
mir das automatisch macht.

Leider funktioniert kein "use $0", das waere am einfachsten gewesen. Aber
das haben die Perl-Entwickler leider nicht vorgesehen.


> Die Frage ist, warum du selber eigene Module verwendest und
> nicht gleich den ganzen Code in eine Datei packst?

Weil die Programme und Module laengst geschrieben sind. Ich hab teilweise
20 Jahre alten Code im Einsatz :-)


> Wie sollen deine Benutzer übrigens das Skript aufrufen?

Ueber den Namen.

--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Ulli Horlacher wrote:
> Ferry Bolhar wrote:
>>Ulli Horlacher:
>>>
>>>cat script module1 module2 ... >script_standalone
>>>$EDITOR script_standalone
>>>(use, package und Exporter Anweisungen auskommentieren)
>>
>>Vorsicht! "package" entfernen kann problematisch sein, wenn dein
>>Hauptcode und ein Modul denselben Namen für eine Variable oder
>>Funktion verwenden.
>
> Ja, das ist mir klar. Darauf achte ich schon. Deshalb such ich ja was, das
> mir das automatisch macht.

Für das Zusammenführen x-beliebiger Module kann es sicherlich
keinen Automatismus geben. Das Beste, was du IMO tun kannst, ist,
dass du das, was du bislang händisch machst, mit einem
selbstgeschriebenen Skript automatisierst.

> Leider funktioniert kein "use $0", das waere am einfachsten gewesen. Aber
> das haben die Perl-Entwickler leider nicht vorgesehen.

Was soll das tun?

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Ulli Horlacher writes:

> Andreas Thul wrote:
> >
> > Hallo,
> >
> > On 11.10.2007 17:53, Ulli Horlacher wrote:
> >
> > > Das muss doch auch eleganter,einfacher gehen?
> >
> > wie wär's mit
>
> Das generiert executables, was fuer mich voellig unbrauchbar ist. Meine
> Ziel-User haben andere Betriebsysteme und andere Hardware als ich.
>
> Ich will nur Hauptprogramm und Modul in ein File zusammenpacken und das
> ohne viel Aufwand.

Lies mal die Dokumentation genauer. Da gibt es Optionen wie

Create stand-alone perl script; do not package to a standalone binary.

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de

tkruler - Perl/Tk program for measuring screen distances
http://ptktools.sourceforge.net/#tkruler

Re: script und module zusammenfassen?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4B76839A5C21B436C8B82C88
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hallo,

Ulli Horlacher wrote:
> Ich habe einige selbstgeschriebene Scripte, die wiederum
> selbstgeschriebene Module mittels use importieren. Das funktioniert bei=

> mir alles bestens, weil die Module in @INC stehen.
>=20
> Jetzt moechte ich diese Programme an Kollegen weitergehen, die von Perl=

> gar nichts und von UNIX sehr wenig wissen. Denen zu erklaeren, was sie =
wie
> wo installieren muessen ist sehr schwierig.
>=20
> Ich wuerden daher denen gerne Script und Modul zusammen in einem File
> schicken.

Z.B. in einem .tar.gz, das sie entpacken, 'perl Makefile.PL; make; sudo
make install' ausführen und gut ist?

Wenn die Kollegen alle die selbe Distribution benutzen, kannst du ihnen
auch Pakete für ihre Distri bauen - das ist Idiotensicher zu
installieren (.oO(hoffe ich;) ).

Grüße,
Moritz

--=20
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/


--------------enig4B76839A5C21B436C8B82C88
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDoMjAAkekJBI0yIRAga6AKDMaTgUDL+8e6Nx0LUfGtsx5sI+/gCe NaLQ
74X8398epnqo7nO4v8e6pvo=
=buzb
-----END PGP SIGNATURE-----

--------------enig4B76839A5C21B436C8B82C88--

Re: script und module zusammenfassen?

Frank Seitz wrote:

> Für das Zusammenführen x-beliebiger Module kann es sicherlich
> keinen Automatismus geben. Das Beste, was du IMO tun kannst, ist,
> dass du das, was du bislang händisch machst, mit einem
> selbstgeschriebenen Skript automatisierst.

Klar, so was krieg ich schon selber hin. Nur dachte ich, dass ich nicht
der erste bin, der so was braucht. Ich bin bekennender
Code-Wiederverwerter :-)


> > Leider funktioniert kein "use $0", das waere am einfachsten gewesen. Aber
> > das haben die Perl-Entwickler leider nicht vorgesehen.
>
> Was soll das tun?

Sich selber als Modul zu laden.
Also vor allem die Funktionen der unten angehaengten packages in den main
Namespace zu importieren.


--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Slaven Rezic wrote:

> > Ich will nur Hauptprogramm und Modul in ein File zusammenpacken und das
> > ohne viel Aufwand.
>
> Lies mal die Dokumentation genauer. Da gibt es Optionen wie
>
> Create stand-alone perl script; do not package to a standalone binary.

framstag@fex:/sw/share/fstools-0.0/bin: pp -P -o utf utfrecode

framstag@fex:/sw/share/fstools-0.0/bin: l utf*
-RWX 634,003 07-10-11 22:54 utf
-RWX 880 07-10-11 19:29 utfrecode

Grad mal Faktor 1000 groesser. Aechz.

--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Ulli Horlacher writes:

> Slaven Rezic wrote:
>
> > > Ich will nur Hauptprogramm und Modul in ein File zusammenpacken und das
> > > ohne viel Aufwand.
> >
> > Lies mal die Dokumentation genauer. Da gibt es Optionen wie
> >
> > Create stand-alone perl script; do not package to a standalone binary.
>
> framstag@fex:/sw/share/fstools-0.0/bin: pp -P -o utf utfrecode
>
> framstag@fex:/sw/share/fstools-0.0/bin: l utf*
> -RWX 634,003 07-10-11 22:54 utf
> -RWX 880 07-10-11 19:29 utfrecode
>
> Grad mal Faktor 1000 groesser. Aechz.
>

Möglicherweise wurden *alle* Perl-Module, die dein Skript braucht
eingepackt. Vielleicht kann man soweit tunen, dass die Core-Module
nicht eingepackt werden? Oder vielleicht hast du viele
nicht-Core-Module benutzt?

--
Slaven Rezic - slaven rezic de

tknotes - A knotes clone, written in Perl/Tk.
http://ptktools.sourceforge.net/#tknotes

Re: script und module zusammenfassen?

Slaven Rezic wrote:

> > framstag@fex:/sw/share/fstools-0.0/bin: pp -P -o utf utfrecode
> >
> > framstag@fex:/sw/share/fstools-0.0/bin: l utf*
> > -RWX 634,003 07-10-11 22:54 utf
> > -RWX 880 07-10-11 19:29 utfrecode
> >
> > Grad mal Faktor 1000 groesser. Aechz.
> >
>
> Möglicherweise wurden *alle* Perl-Module, die dein Skript braucht
> eingepackt. Vielleicht kann man soweit tunen, dass die Core-Module
> nicht eingepackt werden?

Das ist default bei -P:

-B, --bundle
Bundle core modules in the resulting package. This option is enabled by default, except when "-p" or "-P" is specified.


> Oder vielleicht hast du viele nicht-Core-Module benutzt?

Eines, mit 2 kB.

Ich versuch jetzt doch mal einen module-packer selber zu schreiben.

--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Ulli Horlacher writes:

> Slaven Rezic wrote:
>
> > > framstag@fex:/sw/share/fstools-0.0/bin: pp -P -o utf utfrecode
> > >
> > > framstag@fex:/sw/share/fstools-0.0/bin: l utf*
> > > -RWX 634,003 07-10-11 22:54 utf
> > > -RWX 880 07-10-11 19:29 utfrecode
> > >
> > > Grad mal Faktor 1000 groesser. Aechz.
> > >
> >
> > Möglicherweise wurden *alle* Perl-Module, die dein Skript braucht
> > eingepackt. Vielleicht kann man soweit tunen, dass die Core-Module
> > nicht eingepackt werden?
>
> Das ist default bei -P:
>
> -B, --bundle
> Bundle core modules in the resulting package. This option is enabled by default, except when "-p" or "-P" is specified.
>
>
> > Oder vielleicht hast du viele nicht-Core-Module benutzt?
>
> Eines, mit 2 kB.
>
> Ich versuch jetzt doch mal einen module-packer selber zu schreiben.
>

Schau mal ins generierte Skript mit "unzip -l" rein. Da hängt nämlich
ein ZIP-Archiv dran. Vielleicht hast du doch non-Core-Module
verwendet? Wenn man beispielsweise ActivePerl verwendet, ist es einem
nicht klar, was Core ist und was nicht.

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de

tknotes - A knotes clone, written in Perl/Tk.
http://ptktools.sourceforge.net/#tknotes

Re: script und module zusammenfassen?

Ulli Horlacher wrote:
> Frank Seitz wrote:
>>
>>Für das Zusammenführen x-beliebiger Module kann es sicherlich
>>keinen Automatismus geben. Das Beste, was du IMO tun kannst, ist,
>>dass du das, was du bislang händisch machst, mit einem
>>selbstgeschriebenen Skript automatisierst.
>
> Klar, so was krieg ich schon selber hin. Nur dachte ich, dass ich nicht
> der erste bin, der so was braucht. Ich bin bekennender
> Code-Wiederverwerter :-)

Vielleicht geht es doch. Die Anweisung "use P1" ist,
wenn ich es richtig sehe, äquivalent zu:


package ;
P1->import() if P1->can('import');

Diese Ersetzung müsstest du, ausgehend vom Hauptprogramm,
rekursiv über allen Moduldateien durchführen, wobei nur der erste
use-Aufruf eines Moduls zählt, alle weiteren sind Nulloperationen.

>>>Leider funktioniert kein "use $0", das waere am einfachsten gewesen. Aber
>>>das haben die Perl-Entwickler leider nicht vorgesehen.
>>
>>Was soll das tun?
>
> Sich selber als Modul zu laden.
> Also vor allem die Funktionen der unten angehaengten packages in den main
> Namespace zu importieren.

Sorry, aber das ist mit Sicherheit nicht hinreichend.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Ulli Horlacher:

> Leider funktioniert kein "use $0", das waere am einfachsten gewesen. Aber
> das haben die Perl-Entwickler leider nicht vorgesehen.

'use' ist eine Compilerdirektive (wie auch 'package'), sie wird
direkt vom Parser verarbeitet. Die Interpolation von Variablen
passiert hingegen erst zur Laufzeit. Daher kann dein Ansatz nicht
funktionieren.

> > Die Frage ist, warum du selber eigene Module verwendest und
> > nicht gleich den ganzen Code in eine Datei packst?
>
> Weil die Programme und Module laengst geschrieben sind. Ich hab teilweise
> 20 Jahre alten Code im Einsatz :-)
>
>
> > Wie sollen deine Benutzer übrigens das Skript aufrufen?
>
> Ueber den Namen.

Ich habe nur gefragt, weil du geschrieben hast, dass das Skript
unter verschiedenen UNIX-Derivaten laufen soll (zumindest hatte
ich das so verstanden). Das heißt dann, dass du u.U. auch noch
unterschiedliche Pfade zum Perl-Exe in der Shebang-Zeile berück-
sichtigen musst.

Ich fürchte, für dein Problem gibt es keine allgemeine Lösung,
du wirst dir wohl etwas basteln müssen, wobei vielleicht folgendes
hilft:

1) Code in einer Moduldatei ist Code in einem eigenen Scope.
Wird dieser Code mittels 'use' eingebunden, wird er im Context
eines BEGIN-Blocks kompiliert und ggf. auch gleich ausgeführt.
Du solltest also für jedes Modul die .pm-Datei einlesen und im
Hauptcode folgendes schreiben:

BEGIN {
package MODUL;
#... Restlicher Code aus der ModulDatei
}

Du solltest dabei die Reihenfolge einhalten, in der auch die 'use'
Direktiven im ursprünglichen Programm vorkommen.

Das '1;' am Ende kannst du weglassen; das ist nur wichtig, wenn
die Datei mittels 'use' bzw 'require' (das 'use' intern verwendet,
siehe weiter unten) geladen wird, was ja hier nicht mehr der Fall
ist.

2) Ein 'use MODUL;' entspricht einem

BEGIN {
require MODUL;
MODUL->import(@_) if MODUL->can('import');
}

Das 'require' fällt hier weg (der Modulcode ist ja schon in der
Datei), falls aber deine Module 'import'-Methoden bereitstellen,
ist es wichtig, dass du sie so (d.h., in BEGIN-Blöcken) aufrufst,
und zwar nachdem der Modulcode kompiliert wurde. Also für
jedes Modul im Prinzip:

BEGIN {
package MODUL1;
# Rest von MODUL1.pm
MODUL1->import(@args) if MODUL1->can('import');
}

BEGIN {
package MODUL2;
# Rest von MODUL2.pm
MODUL2->import(@args) if MODUL2->can('import');
}

Das @args Array wird dabei aus den Argumenten, die nach
den jeweiligen 'use' Direktiven folgen, gebildet. Fehlen diese,
kann es, nicht aber der Aufruf der 'import'-Methode selbst
weggelassen werden. Rufst du im ursprünglichen Code deine
Module mit

use MODUL ();

auf, dann wird eine 'import'-Methode, auch wenn sie vorhanden
ist, nicht ausgeführt; du brauchst dann deren Aufruf nicht in
deinen Code aufnehmen.

Das Ganze gilt natürlich auch sinngemäß für 'unimport' (falls
deine Module auch die 'no MODUL;' Schreibweise unterstützen).

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

Ferry Bolhar wrote:
>
> BEGIN {
> package MODUL1;
> # Rest von MODUL1.pm
> MODUL1->import(@args) if MODUL1->can('import');
> }

Der Aufruf von import() ist da nicht richtig. Er
muss im Scope des Package stehen, das use aufruft, also
nach dem Block. Das BEGIN ist, denke ich, überflüssig.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Ferry Bolhar wrote:
>
> BEGIN {
> package MODUL1;
> # Rest von MODUL1.pm
> MODUL1->import(@args) if MODUL1->can('import');
> }

Der Aufruf von import() ist da nicht richtig. Er
muss im Scope des Package stehen, das use aufruft, also
nach dem Block. Das "package MODUL1" ist zu viel,
denn "use MODUL1" impliziert dies nicht, dadurch kann
was kaputt gehen. Das BEGIN ist, denke ich, überflüssig,

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Hallo,

> Ich habe einige selbstgeschriebene Scripte, die wiederum
> selbstgeschriebene Module mittels use importieren. Das funktioniert bei
> mir alles bestens, weil die Module in @INC stehen.

Ich habe eine ähnliche Situation, allerdings kann ich alles ausführen,
ohne die Module extra mit möglicherweise direktem Pfad in @INC
einzutragen. Der aktuelle Ordner ist ja normalerweise in @INC.

> Jetzt moechte ich diese Programme an Kollegen weitergehen, die von Perl
> gar nichts und von UNIX sehr wenig wissen. Denen zu erklaeren, was sie wie
> wo installieren muessen ist sehr schwierig.

> Ich wuerden daher denen gerne Script und Modul zusammen in einem File
> schicken.

Wäre ein zip-Archiv in Ordnung, das sie auspacken? Das Hauptprogramm
ist im root-Ordner, der Rest in Unterordnern?

Dann hätte ich folgenden Vorschlag: im Programmverzeichnis, das
komplett ins zip-Archiv gepackt wird:

myprog.pl -- die Hauptdatei zum Ausführen
Mymodules.pm -- Hauptdatei zum Einbinden der Module
Mymodules -- Ordner, wo die "Unter-Module" drin sind

in myprog.pl steht dann

use Mymodules;
use Mymodules::Untermodul1;
print Mymodules::Untermodul2::someSub1();

In Mymodules.pm steht:

package Mymodules;
use Mymodules::Untermodul1;
use Mymodules::Untermodul2;
return 1;

Dann fehlen nur noch die Untermodule, die Du in den Ordner Mymodules
tust, Beispiel Mymodules/Untermodul2.pm:

package Mymodules::Untermodul2;
use Exporter();
our (@ISA, @EXPORT, @EXPORT_OK);
@ISA =3D qw(Exporter);
@EXPORT =3D qw(someSub);
sub someSub {
return "foo";
}
return 1;

Das ganze habe ich so bei einem Parser für Instant Messenger Histories
gelöst und das funktioniert bei mir auf unterschiedlichsten Rechnern
ohne Installation oder Verändern von @INC oder anderen Pfadvariablen.
Ich hab die Beispiele hier sinngemäß übernommen, stammt sozusagen von
meinem eigenen Code von http://impuls.sourceforge.net 8-)

Du hättest es dann zwar nicht alles in einer Datei, aber das Archiv
auspacken und die Hauptdatei starten, sollte auch die Kollegen nicht
überfordern. Außerdem braucht man keine root-Rechte um den Kram zu
installieren. Ob das jetzt sauber ist, keine Ahnung, läuft aber.

HTH
Alex

Re: script und module zusammenfassen?

Frank Seitz:

> Der Aufruf von import() ist da nicht richtig. Er
> muss im Scope des Package stehen, das use aufruft, also
> nach dem Block.

Wie kommst du denn darauf? Die import-Methode wird
im Scope der Moduldatei aufgerufen:

In y.pm:
package y;
my $y = 'Ich bin y!';
sub import {
my $pkg = shift;
print "Package: $pkg, y = $y\n";
}
1;

In x.pl:
use y;

Ergibt:

Package: y, y: Ich bin y!

Stünde der Aufruf von import() im Scope des Aufrufers,
dann wäre die lexikalische Variable $y nicht ansprechbar.
Außerdem wäre dann der Wert des ersten, an die Methode
übergebenen Arguments 'main' und nicht 'y'.

> Das "package MODUL1" ist zu viel,
> denn "use MODUL1" impliziert dies nicht, dadurch kann
> was kaputt gehen.

Das stimmt, allerdings gehe ich davon aus, dass ein Modul,
das mit 'use' eingebunden wird, am Beginn eine 'package'
Direktive hat. Alles andere wäre IMHO grober Unfug.

> Das BEGIN ist, denke ich, überflüssig,

Es ist nicht überflüssig, wenn der Modulecode Dinge tut,
die auf den späteren Kompilierprozess Einfluss haben, also
z.B. das Manipulation von Symboltabellen. Wenn es sich
nur um Funktions- oder Methodendeklarationen handelt,
braucht man es nicht, da stimme ich dir zu.

Da ich die Code der Module des OP nicht kenne, wollte
ich auf Nummer sicher gehen und das, was bei einem 'use'
normalerweise passiert, eben möglichst genau nachbilden.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

Hi

Ulli Horlacher schrieb:
> Ich habe einige selbstgeschriebene Scripte, die wiederum
> selbstgeschriebene Module mittels use importieren. Das funktioniert bei=

> mir alles bestens, weil die Module in @INC stehen.
>=20
> Jetzt moechte ich diese Programme an Kollegen weitergehen, die von Perl=

> gar nichts und von UNIX sehr wenig wissen. Denen zu erklaeren, was sie =
wie
> wo installieren muessen ist sehr schwierig.
>=20
> Ich wuerden daher denen gerne Script und Modul zusammen in einem File
> schicken.
>=20
> Bisher mach ich von Hand:
>=20
> cat script module1 module2 ... >script_standalone
> $EDITOR script_standalone
> (use, package und Exporter Anweisungen auskommentieren)
>=20
> Das muss doch auch eleganter,einfacher gehen?
>=20

Hast Du schon mal daran gedacht, daß von einem C-Precompiler=20
machen zu lassen?
Da die Anweisungen mit dem Perl Kommentarzeichen beginnen, sollte=20
sich Perl nicht daran stören
#include

und die nicht gewollten Anweisungen könntest Du mit
#ifdef, #ifndef
rausschmeißen.

Ich habe es zwar noch nicht ausprobiert, aber es sollte gehen.

--=20
Schönen Gruß aus dem Bergischen Land
Robert

Re: script und module zusammenfassen?

Ferry Bolhar wrote:
> Frank Seitz:
>>
>>Der Aufruf von import() ist da nicht richtig. Er
>>muss im Scope des Package stehen, das use aufruft, also
>>nach dem Block.
>
> Wie kommst du denn darauf? Die import-Methode wird
> im Scope der Moduldatei aufgerufen:
>
> In y.pm:
> package y;
> my $y = 'Ich bin y!';
> sub import {
> my $pkg = shift;
> print "Package: $pkg, y = $y\n";
> }
> 1;
>
> In x.pl:
> use y;
>
> Ergibt:
>
> Package: y, y: Ich bin y!

Es geht nicht um den ersten Parameter von import(),
sondern darum, was caller() liefert. Das muss in deinem
Beispiel "main" sein und darf nicht "y" sein.

> Stünde der Aufruf von import() im Scope des Aufrufers,
> dann wäre die lexikalische Variable $y nicht ansprechbar.

Natürlich ist die ansprechbar, denn sie wird in
import() genutzt. Das hat mit dem Aufrufer nichts zu tun.

>>Das "package MODUL1" ist zu viel,
>>denn "use MODUL1" impliziert dies nicht, dadurch kann
>>was kaputt gehen.
>
> Das stimmt, allerdings gehe ich davon aus, dass ein Modul,
> das mit 'use' eingebunden wird, am Beginn eine 'package'
> Direktive hat. Alles andere wäre IMHO grober Unfug.

Nein, das ist kein grober Unfug. Die package-Deklaration
kann fehlen oder es können in dem Modul Packages
vereinbart werden, die anders heißen als das Modul.
Das ist alles völlig legal und kann sinnvoll sein.

>> Das BEGIN ist, denke ich, überflüssig,
>
> Es ist nicht überflüssig, wenn der Modulecode Dinge tut,
> die auf den späteren Kompilierprozess Einfluss haben, also
> z.B. das Manipulation von Symboltabellen.

Hast du mal ein Beispiel?

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Frank Seitz:

> Es geht nicht um den ersten Parameter von import(),
> sondern darum, was caller() liefert. Das muss in deinem
> Beispiel "main" sein und darf nicht "y" sein.

OK, hast recht. Danke! Ich hatte schon zwei BEGIN-Blöcke
untereinander geschrieben gehabt, und sie dann "zwecks Ver-
einfachung" erst wieder auf einen reduziert... :-(

Dennoch sollte der Aufruf von import() in einem BEGIN-
Block stehen, damit die bei 'use' übliche Reihenfolge gewahrt
bleibt. Also jetzt die (hoffentlich) letzte Fassung:

my @args;

BEGIN {
package MODUL1;
# Rest von MODUL1.pm und
# @args aus 'use' Anweisung bilden, falls nötig
}
BEGIN {
__PACKAGE__->import(@args);
}

> Natürlich ist die ansprechbar, denn sie wird in
> import() genutzt. Das hat mit dem Aufrufer nichts zu tun.

Dann hatte ich dich scheinbar falsch verstanden.

>> Das stimmt, allerdings gehe ich davon aus, dass ein Modul,
>> das mit 'use' eingebunden wird, am Beginn eine 'package'
>> Direktive hat. Alles andere wäre IMHO grober Unfug.
>
> Nein, das ist kein grober Unfug. Die package-Deklaration
> kann fehlen oder es können in dem Modul Packages
> vereinbart werden, die anders heißen als das Modul.
> Das ist alles völlig legal und kann sinnvoll sein.

Kannst du mir ein Beispiel für ein mit 'use' eingebundenes
Modul geben, das keinerlei 'package' Deklaration enthält?
Ein Modul kann ohne weiteres mehrere solche Deklarationen
enthalten (zB. B.pm tut das), aber ganz ohne? Nicht dass es
nicht gehen würde, aber das wäre dann eher eine mit 'require'
einzubindende Perl-Library, wie es sie in Perl 4 gab, als das,
was man per Definition unter einem Modul versteht.

>> Es ist nicht überflüssig, wenn der Modulecode Dinge tut,
>> die auf den späteren Kompilierprozess Einfluss haben, also
>> z.B. das Manipulation von Symboltabellen.
>
> Hast du mal ein Beispiel?

vars, subs, fields, overload, um nur einige auf die Schnelle
zu nennen. Gibt aber sicher noch mehr (z.B. alles, was mit
Source Filtern zu tun hat).

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

Ulli Horlacher schrieb:
> Ich habe einige selbstgeschriebene Scripte, die wiederum
> selbstgeschriebene Module mittels use importieren. Das funktioniert bei
> mir alles bestens, weil die Module in @INC stehen.
>
> Jetzt moechte ich diese Programme an Kollegen weitergehen, die von Perl
> gar nichts und von UNIX sehr wenig wissen. Denen zu erklaeren, was sie wie
> wo installieren muessen ist sehr schwierig.
>
> Ich wuerden daher denen gerne Script und Modul zusammen in einem File
> schicken.
>
> Bisher mach ich von Hand:
>
> cat script module1 module2 ... >script_standalone
> $EDITOR script_standalone
> (use, package und Exporter Anweisungen auskommentieren)
>
> Das muss doch auch eleganter,einfacher gehen?

Einfacher: nein.

Einen rudimentären, mit Problemen behafteten Ansatz eines
Packagers, der Module aus beliebigen Pfaden in @INC findet,
einen "Selfextractor" in ein Perlscript schreibt und dort
alle Dateien Base64-kodiert in den Data-Block hängt, habe
ich mal auf http://www.a-za-z0-9.de/perl/mkpackage.zip
abgelegt. Beim Entpacken wird (via File:Temp) eine temporäre
Ordnerstruktur angelegt und dem Ursprungsscript der Pfad
ins @INC geschoben.

Mir fallen allerdings ungefähr tausend Dinge ein, die da
falsch laufen können (und in der Praxis vermutlich auch
werden), z.B. Shebang-Line, Zeilenenden, Zeichensatzweite
oder der Wert von $^X.

-Christian

Re: script und module zusammenfassen?

Ferry Bolhar wrote:
>
> Also jetzt die (hoffentlich) letzte Fassung:
>
> my @args;
>
> BEGIN {
> package MODUL1;
> # Rest von MODUL1.pm und
> # @args aus 'use' Anweisung bilden, falls nötig
> }
> BEGIN {
> __PACKAGE__->import(@args);
> }

Das ist noch nicht richtig, da es MODUL1->import(@args)
heißen muss und außerdem vor Aufruf getestet werden muss,
ob die Methode überhaupt existiert.

> Kannst du mir ein Beispiel für ein mit 'use' eingebundenes
> Modul geben, das keinerlei 'package' Deklaration enthält?
> Ein Modul kann ohne weiteres mehrere solche Deklarationen
> enthalten (zB. B.pm tut das), aber ganz ohne? Nicht dass es
> nicht gehen würde, aber das wäre dann eher eine mit 'require'
> einzubindende Perl-Library, wie es sie in Perl 4 gab, als das,
> was man per Definition unter einem Modul versteht.

Der Punkt ist, dass die Sprache es erlaubt. Es kann auch Code vor
der Package-Deklaration stehen. Es leuchtet nicht ein,
warum du eine Package-Deklaration vor den inkludierten Code
schreiben willst, die bestenfalls nutzlos ist und im ungünstigen
Fall etwas kaputt macht.

>>>Es ist nicht überflüssig, wenn der Modulecode Dinge tut,
>>>die auf den späteren Kompilierprozess Einfluss haben, also
>>>z.B. das Manipulation von Symboltabellen.
>>
>>Hast du mal ein Beispiel?
>
> vars, subs, fields, overload, um nur einige auf die Schnelle
> zu nennen. Gibt aber sicher noch mehr (z.B. alles, was mit
> Source Filtern zu tun hat).

Ok, abgefahrene Fälle mag es geben.
Die eigentliche Substitution sieht so aus:

{
# Code aus P.pm
}
P->import(@a) if P->can('import');

Um sicher zu gehen, setzt man ein BEGIN{} drumrum.
Dies gilt für's erste use, bei allen weiteren erscheint nur die
Zeile mit import().

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

On 11 Okt., 17:53, Ulli Horlacher
wrote:
> Ich habe einige selbstgeschriebene Scripte, die wiederum
> selbstgeschriebene Module mittels use importieren. Das funktioniert bei
> mir alles bestens, weil die Module in @INC stehen.
>
> Jetzt moechte ich diese Programme an Kollegen weitergehen, die von Perl
> gar nichts und von UNIX sehr wenig wissen. Denen zu erklaeren, was sie wie
> wo installieren muessen ist sehr schwierig.
>
> Ich wuerden daher denen gerne Script und Modul zusammen in einem File
> schicken.
>
> Bisher mach ich von Hand:
>
> cat script module1 module2 ... >script_standalone
> $EDITOR script_standalone
> (use, package und Exporter Anweisungen auskommentieren)
>
> Das muss doch auch eleganter,einfacher gehen?

Einfacher, ja.
Laß doch die ganzen Anweisungen drin und ersetze nur use P qw(x y z)
durch
BEGIN { P->import(qw(x y z)) if P->can("import") }

Dies setzt allerdings voraus, daß Du die Module topologisch nach
Abhängigkeiten sortieren kannst. Das eigentliche Script muß dann als
letztes kommen.

Re: script und module zusammenfassen?

Frank Seitz:

> Das ist noch nicht richtig, da es MODUL1->import(@args)
> heißen muss und außerdem vor Aufruf getestet werden muss,
> ob die Methode überhaupt existiert.

Freilich. Das kann ja gleich der Code, der die BEGIN-Blöcke
erzeugt, machen. Gibt es keine solche Methode, braucht der
zweite BEGIN-Block gar nicht erst erzeugt werden. Ich hätte
gedacht, dass das aus meinem Posting hervorgegangen wäre.

> > Kannst du mir ein Beispiel für ein mit 'use' eingebundenes
> > Modul geben, das keinerlei 'package' Deklaration enthält?
> > Ein Modul kann ohne weiteres mehrere solche Deklarationen
> > enthalten (zB. B.pm tut das), aber ganz ohne? Nicht dass es
> > nicht gehen würde, aber das wäre dann eher eine mit 'require'
> > einzubindende Perl-Library, wie es sie in Perl 4 gab, als das,
> > was man per Definition unter einem Modul versteht.
>
> Der Punkt ist, dass die Sprache es erlaubt.

Die Sprache erlaubt vieles. Deswegen muss man nicht alles
Erlaubte auch tun. Siehe u.a. das PBP-Buch.

> Es kann auch Code vor
> der Package-Deklaration stehen. Es leuchtet nicht ein,
> warum du eine Package-Deklaration vor den inkludierten Code
> schreiben willst, die bestenfalls nutzlos ist und im ungünstigen
> Fall etwas kaputt macht.

Du findest also "package" Anweisungen nutzlos?

Was soll sie denn kaputt machen? Im ursprünglichen Code
steht sie ja auch da! Viel eher ist die Gefahr, dass etwas kaputt
geht, wenn sie nicht dasteht, weil dann sämtlicher Modulcode
nach "main" kompiliert wird, und das kann tatsächlich gefährlich
werden.

Gibt es in der .pm Datei kein "package", braucht auch im
generierten Code keines vorkommen. Sonst aber schon. Und
ich gehe, wie gesagt, davon aus, dass in jedem "vernünftigen"
Modulcode am Beginn ein "package" vorkommt. Alles andere
ist kein Modulcode, sondern eine (nicht mehr zeitgemäße)
Perl-4 Library. Sorry.

Wieviele Moduldateien der Perl-Distribution enthalten _keine_
"package"-Deklaration?

> Ok, abgefahrene Fälle mag es geben.

Ja, wenn man "vars" und "subs" (oder auch den Exporter, der
funktionert genau nach demselben Prinzip) als "abgefahren"
bezeichnen möchte.

> Die eigentliche Substitution sieht so aus:
>
> {
> # Code aus P.pm
> }
> P->import(@a) if P->can('import');
>
> Um sicher zu gehen, setzt man ein BEGIN{} drumrum.

Du solltest dir die Wirkungsweise von "package", speziell im
Zusammenhang mit statischen Methoden und Vererbung, noch
einmal vor Augen führen -> perlmod, perlobj.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

Ferry Bolhar wrote:
> Frank Seitz:
>>
>>Das ist noch nicht richtig, da es MODUL1->import(@args)
>>heißen muss und außerdem vor Aufruf getestet werden muss,
>>ob die Methode überhaupt existiert.
>
> Freilich. Das kann ja gleich der Code, der die BEGIN-Blöcke
> erzeugt, machen. Gibt es keine solche Methode, braucht der
> zweite BEGIN-Block gar nicht erst erzeugt werden. Ich hätte
> gedacht, dass das aus meinem Posting hervorgegangen wäre.

Du machst es zu kompliziert. Das muss der generierende
Code nicht wissen und folglich auch nicht herausfinden,
Das ist eine Aufgabe für sich, die selbst schwierig sein kann.

>>Der Punkt ist, dass die Sprache es erlaubt.
>
> Die Sprache erlaubt vieles. Deswegen muss man nicht alles
> Erlaubte auch tun. Siehe u.a. das PBP-Buch.

Für dich selbst kannst du das frei entscheiden.
Aber für fremden Code?

>>Es kann auch Code vor
>>der Package-Deklaration stehen. Es leuchtet nicht ein,
>>warum du eine Package-Deklaration vor den inkludierten Code
>>schreiben willst, die bestenfalls nutzlos ist und im ungünstigen
>>Fall etwas kaputt macht.
>
> Du findest also "package" Anweisungen nutzlos?

Natürlich nicht allgemein, sondern in deinem Code.

> Was soll sie denn kaputt machen?

Wenn im Modul Code steht, der keinem Package zugeordnet
ist, ordnest du ihn mit deiner zusätzlichen Package-Deklaration
einem falschen Package zu.

> Im ursprünglichen Code steht sie ja auch da!

Nicht zwingend. Was in einer Moduldatei steht,
ist nirgends festgelegt.

> Viel eher ist die Gefahr, dass etwas kaputt
> geht, wenn sie nicht dasteht, weil dann sämtlicher Modulcode
> nach "main" kompiliert wird, und das kann tatsächlich gefährlich
> werden.

Dann war das vom Autor beabsichtigt.

> Gibt es in der .pm Datei kein "package", braucht auch im
> generierten Code keines vorkommen. Sonst aber schon.

Darüber brauchst du dir doch überhaupt keine Gedanken zu machen!
Wenn eine Package-Deklaration im Modul vorkommt, wird sie
ohnehin mit dem Code hineinsubstituiert.

> Und
> ich gehe, wie gesagt, davon aus, dass in jedem "vernünftigen"
> Modulcode am Beginn ein "package" vorkommt. Alles andere
> ist kein Modulcode, sondern eine (nicht mehr zeitgemäße)
> Perl-4 Library. Sorry.

Packages gab es schon in Perl4 (nur hatten sie wegen fehlender
Objektorientierung dort nicht die Bedeutung).

> Wieviele Moduldateien der Perl-Distribution enthalten _keine_
> "package"-Deklaration?

Keine Ahnung. Das ist für meine Argumentation auch egal.

>>Ok, abgefahrene Fälle mag es geben.
>
> Ja, wenn man "vars" und "subs" (oder auch den Exporter, der
> funktionert genau nach demselben Prinzip) als "abgefahren"
> bezeichnen möchte.

Zeige mir mal ein *konkretes* Beispiel, wo die uses durch
Substitution aufgelöst wurden, und welches ohne BEGIN nicht
funktioniert. Das ist dann, so vermute ich, etwas sehr Vertracktes,
use vars und use subs für sich sind meiner Meinung nach
überhaupt kein Problem.

>>Die eigentliche Substitution sieht so aus:
>>
>>{
>># Code aus P.pm
>>}
>>P->import(@a) if P->can('import');
>>
>>Um sicher zu gehen, setzt man ein BEGIN{} drumrum.
>
> Du solltest dir die Wirkungsweise von "package", speziell im
> Zusammenhang mit statischen Methoden und Vererbung, noch
> einmal vor Augen führen -> perlmod, perlobj.

Ferry, wenn in P.pm eine Package-Deklaration steht, dann
kommt sie in obigem Block auch vor, und muss nicht extra dazu
geschrieben werden. Verstehst du?

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Frank Seitz:

> Ferry, wenn in P.pm eine Package-Deklaration steht, dann
> kommt sie in obigem Block auch vor, und muss nicht extra dazu
> geschrieben werden. Verstehst du?

Ich glaube, wir reden hier aneinander vorbei bzw. habe ich mich
vielleicht (wieder mal ;-) unklar ausgedrückt.

Meine ursprüngliches Beispiel:

BEGIN {
package MODUL1;
# Rest von MODUL1.pm
MODUL1->import(@args) if MODUL1->can('import');
}

hat möglicherweise falsch impliziert, dass die "package" Anweisung
in jedem Fall und extra zum übrigen Code hinzukommt. Das hatte ich
aber nicht gemeint; vielmehr meinte ich, dass hier (also bereits mit der
Anweisung) der ursprüngliche, sonst mit "use" geladene Modulcode
einzubinden ist. Oder anders gesagt: der gesamte Modulcode, ein-
schließlich einer - optionalen - "package" Deklaration, ist in einen
BEGIN-Block zu setzen, damit er zum selben Zeitpunkt im selben
Scope wie bei einem "use" geladen und kompiliert wird.

Selbstverständlich soll kein "package" generiert werden, wenn es
im Modulcode selbst nicht vorkommt! Allerdings kenne ich - wie
schon erwähnt - kein Modul, das ganz ohne "package" auskommt.
Aber du hast recht, dass es von der Sprache her möglich wäre.

> Du machst es zu kompliziert. Das muss der generierende
> Code nicht wissen und folglich auch nicht herausfinden,
> Das ist eine Aufgabe für sich, die selbst schwierig sein kann.

Ja, unter Berücksichtigung der vom OP erwähnten Forderung, dass
der generierte Code auch auf anderen Rechnern mit anderen
Betriebssystem- und Perlversionen laufen soll, ist es tatsächlich
sinnvoll, die Prüfung auf Vorhandensein von Methoden zur Laufzeit
durchzuführen. Der if-Zusatz von

MODUL->import(@argv) if MODUL->can('import');

kann allerdings trotzdem entfallen, weil Perl das im Falle von "import"
- und nur hier! - selber prüft. Gibt's die "import"-Methode nicht, wird
sie ganz einfach nicht aufgerufen.

Ich habe jetzt übrigens ein solches Ladeskript geschrieben und
testweise einige unserer großen Programme, die schon mit etlichen
"use" beginnen, drüber laufen lassen. Funktioniert ganz gut; man
muss natürlich rekursiv arbeiten, weil ja eine .pm-Datei wiederum
selbst weitere "use" enthalten kann. Daher muss man klarweise auch
ein %INC simulieren (was u.U. aber ohnehin sinnvoll ist, weil es Code
geben kann, der %INC auswertet!). Außerdem muss man natürlich
auch "require" und "do" Befehle berücksichtigen.

Auf diese Weise habe ich festgestellt, dass eines unserer größten
Skripts aus über 22000 Zeilen Perl-Code besteht!

Ach ja: der Spaß endet klarerweise bei Modulen, die DynaLoader
bzw. XSLoader verwenden, d.h., kompilierten Code in Form von
..so (Unix) oder .dll (Windows) Dateien laden. Aber da ist es dann
mit der Plattformunabhängigkeit ohnehin vorbei

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

Ferry Bolhar wrote:
>
> Der if-Zusatz von
>
> MODUL->import(@argv) if MODUL->can('import');
>
> kann allerdings trotzdem entfallen, weil Perl das im Falle von "import"
> - und nur hier! - selber prüft. Gibt's die "import"-Methode nicht, wird
> sie ganz einfach nicht aufgerufen.

Ok. Das ist ja witzig. Wusste ich nicht, dass Perl sich bei
import() anders verhält.

> Ich habe jetzt übrigens ein solches Ladeskript geschrieben und
> testweise einige unserer großen Programme, die schon mit etlichen
> "use" beginnen, drüber laufen lassen.

Ich glaube, ich werde das auch mal bauen, für
Produktions-Installationen kann das interessant sein.
Ich verspreche mir davon eine Verkürzung der Ladezeit.

> Funktioniert ganz gut; man
> muss natürlich rekursiv arbeiten, weil ja eine .pm-Datei wiederum
> selbst weitere "use" enthalten kann.

Logisch.

> Daher muss man klarweise auch
> ein %INC simulieren (was u.U. aber ohnehin sinnvoll ist, weil es Code
> geben kann, der %INC auswertet!). Außerdem muss man natürlich
> auch "require" und "do" Befehle berücksichtigen.

Weiß ich nicht, ob ich %INC faken würde. Was nicht wirklich
geladen wurde, würde ich in %INC auch nicht eintragen.

> Auf diese Weise habe ich festgestellt, dass eines unserer größten
> Skripts aus über 22000 Zeilen Perl-Code besteht!
>
> Ach ja: der Spaß endet klarerweise bei Modulen, die DynaLoader
> bzw. XSLoader verwenden, d.h., kompilierten Code in Form von
> .so (Unix) oder .dll (Windows) Dateien laden. Aber da ist es dann
> mit der Plattformunabhängigkeit ohnehin vorbei

Ich würde es so gestalten, dass man angeben kann, welche
Module inkludiert werden sollen und welche nicht. Core-Module
sollten per Default außen vor bleiben.

Frage an die Allgemeinheit: Wie stelle ich fest,
was ein Core-Modul ist und was nicht?

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Frank Seitz schrieb:

> Frage an die Allgemeinheit: Wie stelle ich fest,
> was ein Core-Modul ist und was nicht?

http://search.cpan.org/~rgarcia/Module-CoreList-2.12/lib/Mod ule/CoreList.pm

:o)

Gruss in die Runde,

Joergen

Re: script und module zusammenfassen?

Frank Seitz schrieb:
> Frage an die Allgemeinheit: Wie stelle ich fest,
> was ein Core-Modul ist und was nicht?

Module::Info oder (ab 5.10 dann im Core) Module::CoreList.
Letzteres bringt auch für jedes Core-Modul die Info mit,
ab welcher Perl-Version es verfügbar ist.

-Christian

Re: script und module zusammenfassen?

Was mir noch dazu einfällt: B::Bytecode. Baut aus einem Perl-Skript
inkl. aller Module ein binäres Programm zusammen, dh., es wird der
fertig kompilierte OP-Tree in eine Datei geschrieben. Die kann dann
mittels ByteLoader geladen und ausgeführt werden. Da es sich - ähnlich
wie bei Java - um Bytecode handelt, mit dem Perl's "Virtuelle Maschine"
(der Interpreter) gefüttert wird, sollte das Ganze plattform- und OS-
unabhängig sein.

Ich weiß allerdings nicht, inwieweit das auch auf unterschiedliche Perl-
Versionen (mit unterschiedlichen Compiler-Optionen) zutrifft. Und
natürlich dürfen auch da keine Module, die Dynaloader/XSLoader
zum Laden von kompilierten C-Code verwenden, vorkommen.

Beide Module gehören zur Standard-Distribution, sollten also überall
vorhanden sein.

Ich hab's einmal mit einem "Hello World!" - Skript ausprobiert, das hat
funktioniert. Wenn dein Code über diese Anforderung hinausgeht, musst
du es selbst damit ausprobieren. ;-))

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

Frank Seitz:

> Ok. Das ist ja witzig. Wusste ich nicht, dass Perl sich bei
> import() anders verhält.

Auch bei unimport(). :-)

>> Ich habe jetzt übrigens ein solches Ladeskript geschrieben und
>> testweise einige unserer großen Programme, die schon mit etlichen
>> "use" beginnen, drüber laufen lassen.
>
> Ich glaube, ich werde das auch mal bauen, für
> Produktions-Installationen kann das interessant sein.
> Ich verspreche mir davon eine Verkürzung der Ladezeit.

Das konnte ich nicht feststellen. Wenn es wirklich Verkürzungen
gibt, dürften sie im Hunderstel-Bereich liegen. Es muss ja dennoch
der gesamte Code kompiliert werden und es wird in beiden Fällen
immer nur eine Datei gleichzeitig eingelesen. Ja, man erspart sich
das Öffnen und Schließen der .pm Dateien, aber die dadurch
gewonnene Zeit dürfte kaum von Bedeutung sein. Aber vielleicht
machst du ja andere Erfahrungen.

>> Daher muss man klarweise auch
>> ein %INC simulieren (was u.U. aber ohnehin sinnvoll ist, weil es Code
>> geben kann, der %INC auswertet!). Außerdem muss man natürlich
>> auch "require" und "do" Befehle berücksichtigen.
>
> Weiß ich nicht, ob ich %INC faken würde. Was nicht wirklich
> geladen wurde, würde ich in %INC auch nicht eintragen.

Naja, irgendwo musst du dir ja ohnehin merken, was schon geladen
wurde, also warum nicht gleich in %INC? Und "geladen" wurde ja
alles, wenn auch anders als auf die herkömmliche Weise.

> Ich würde es so gestalten, dass man angeben kann, welche
> Module inkludiert werden sollen und welche nicht. Core-Module
> sollten per Default außen vor bleiben.
>
> Frage an die Allgemeinheit: Wie stelle ich fest,
> was ein Core-Modul ist und was nicht?

Im Falle des OP gar nicht, weil er seinen Code unter verschiedenen
Perl-Versionen auf verschiedenen Plattformen laufen lassen möchte.
Ein Modul, das in einer neueren Perl-Version schon zum Core
gehört, muss in einer älteren Version noch nicht dabei sein bzw.
wurde es in einer neueren Version aus dem Modul-Core entfernt.
Der Einfachkeit halber würde ich daher, deinen obigen Vorschlag
aufgreifend, eine Option vorsehen, die _alle_ Module einbindet,
und ev. eine zweite, die alle Module außer Pragmas (d.h., solche,
deren Namen mit einem Kleinbuchstaben beginnt) einbindet. Ich
werden meinen Code entsprechend erweitern.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

Frank Seitz wrote:

> Vielleicht geht es doch. Die Anweisung "use P1" ist,
> wenn ich es richtig sehe, äquivalent zu:
>
>
> package ;
> P1->import() if P1->can('import');

Ahhhhhhh!
DAS bringt mich jetzt WESENTLICH weiter! SEHR SCHOEN!
Funktioniert. Danke.

Das war mir bisher naemlich nicht klar. Wo kann man das nachlesen?


--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Frank Seitz wrote:

> Ferry Bolhar wrote:
> >
> > Der if-Zusatz von
> >
> > MODUL->import(@argv) if MODUL->can('import');
> >
> > kann allerdings trotzdem entfallen, weil Perl das im Falle von "import"
> > - und nur hier! - selber prüft. Gibt's die "import"-Methode nicht, wird
> > sie ganz einfach nicht aufgerufen.
>
> Ok. Das ist ja witzig. Wusste ich nicht, dass Perl sich bei
> import() anders verhält.

Ihr diskutiert hier nicht nur unter euch, ich lese noch interessiert mit
und lerne dazu :-)


> > Ich habe jetzt übrigens ein solches Ladeskript geschrieben und
> > testweise einige unserer großen Programme, die schon mit etlichen
> > "use" beginnen, drüber laufen lassen.
>
> Ich glaube, ich werde das auch mal bauen, für
> Produktions-Installationen kann das interessant sein.
> Ich verspreche mir davon eine Verkürzung der Ladezeit.

Das muessten dann aber schon *sehr* viele use Statements sein, damit sich
die Ladezeit signifikant verkuerzt. Es wird dann nur ein file statt n
files gelesen. Die Code-Menge bleibt diesselbe. Oder habe ich was uebersehen?


> Ich würde es so gestalten, dass man angeben kann, welche
> Module inkludiert werden sollen und welche nicht.

Genau so sieht meine Loesung jetzt aus. Mehr brauch ich nicht.

--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Ulli Horlacher:

> Das war mir bisher naemlich nicht klar. Wo kann man das nachlesen?

perldoc -f use

Außerdem in diversen Perl-Büchern (z.B. "Kamel"-Buch).

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

"Frank Seitz":

> Ok. Das ist ja witzig. Wusste ich nicht, dass Perl sich bei
> import() anders verhält.

He! Dass ich dir noch mal etwas Neues erzählen kann... ;-))

Ist übrigens nirgendwo dokumentiert - obwohl nachweislich
seit Perl 5.005 (davon habe ich noch die Sourcen, vermutlich
auch schon früher) und auch noch in 5.9.4 vorhanden. Wahr-
scheinlich wird diese Funktionalität vom Interpreter selber
benötigt. Der Compiler weiß nichts davon, er generiert den
Methodenaufruf wie jeden anderen, erst zur Laufzeit werden
Methoden mit den Namen "import" und "unimport", falls sie
nicht gefunden werden, gesondert behandelt (in der Funktion
"gv_fetchmethod_autoload" in gv.c).

Gut möglich, dass das in Perl 6 nicht mehr so sein wird. Bei
den noch kommenden 5er-Versionen rechne ich nicht mehr
mit einer Änderung.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

Ulli Horlacher wrote:
> Frank Seitz wrote:
>>
>>Vielleicht geht es doch. Die Anweisung "use P1" ist,
>>wenn ich es richtig sehe, äquivalent zu:
>>
>>
>>package ;
>>P1->import() if P1->can('import');
>
> Ahhhhhhh!
> DAS bringt mich jetzt WESENTLICH weiter! SEHR SCHOEN!
> Funktioniert. Danke.

Nimm lieber den Endstand der Diskussion, der entbindet
dich davon herauszufinden, von welchem Package aus geused wird.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Ulli Horlacher wrote:
> Frank Seitz wrote:
>>
>>Ich glaube, ich werde das auch mal bauen, für
>>Produktions-Installationen kann das interessant sein.
>>Ich verspreche mir davon eine Verkürzung der Ladezeit.
>
> Das muessten dann aber schon *sehr* viele use Statements sein, damit sich
> die Ladezeit signifikant verkuerzt. Es wird dann nur ein file statt n
> files gelesen. Die Code-Menge bleibt diesselbe. Oder habe ich was uebersehen?

Ich habe eine umfangreiche Klassenbibliothek, die aus über 100
Moduldateien besteht, Tendenz steigend. Open() ist eine relativ
teure Operation. Die POD-Doku könnte ich ebenfalls strippen.
Der Unterschied müsste sich schon bemerkbar machen.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Ferry Bolhar wrote:

( P1->import() )
> > Das war mir bisher naemlich nicht klar. Wo kann man das nachlesen?
>
> perldoc -f use

Da stehts gleich am Anfang:

BEGIN { require Module; import Module LIST; }

Ok, das require kann ich weglassen, weil ich den Code schon manuell
inkludiert habe und "Module->import(LIST)" und "import Module LIST" sind
wohl identisch, nur unterschiedliche Notation? Letztere ist mir
sympathischer, von OO-Syntax krieg ich Pickel :-)


> Außerdem in diversen Perl-Büchern (z.B. "Kamel"-Buch).

DIE Antwort hab ich geahnt :-)
Nur wo?
Ok, habs inzwischen: Seite 304 "Programming Perl". Man muss nur wissen
wonach genau man suchen muss :-)


--
Ullrich Horlacher Informationssysteme und Serverbetrieb
Rechenzentrum E-Mail: horlacher@rus.uni-stuttgart.de
Universitaet Stuttgart Tel: ++49-711-685-65868
Allmandring 30 Fax: ++49-711-682357
70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/

Re: script und module zusammenfassen?

Ulli Horlacher:

> Da stehts gleich am Anfang:
>
> BEGIN { require Module; import Module LIST; }

Ja, genau das is es.

> Ok, das require kann ich weglassen, weil ich den Code schon manuell
> inkludiert habe

Du kannst es auch hinschreiben. "require" checkt das selbst,
indem es beim ersten Laden den Dateinamen in %INC aufnimmt
und danach, wenn der Modulname als Key in %INC vorkommt,
das nochmalige Laden unterläßt.

und "Module->import(LIST)" und "import Module LIST" sind
> wohl identisch,

Ja.

nur unterschiedliche Notation? Letztere ist mir
> sympathischer, von OO-Syntax krieg ich Pickel :-)

Ist Geschmackssache. Ich schreibe Instanzmethoden lieber mit
der -> Syntax, Klassenmethoden aber lieber mit der Syntax ohne
Pfeil (auch manchmal als "indirekte Objektsyntax" bezeichnet),
weil sie auch in anderen Sprachen üblich ist, wie z.B. in JavaScript:

var MyArray = new Array;

erzeugt in der Variable "MyArray" eine neue Instanz der Klasse
"Array". Die Pfeilsyntax wäre hier gar nicht zulässig.

>> Außerdem in diversen Perl-Büchern (z.B. "Kamel"-Buch).
>
> DIE Antwort hab ich geahnt :-)
> Nur wo?
> Ok, habs inzwischen: Seite 304 "Programming Perl". Man muss nur wissen
> wonach genau man suchen muss :-)

Du hast meine Antwort vorweggenommen. ;-))

LG, Ferry
--

Re: script und module zusammenfassen?

On 2007-10-19 19:32, Ferry Bolhar wrote:
> Ulli Horlacher:
>> Da stehts gleich am Anfang:
>>
>> BEGIN { require Module; import Module LIST; }
>
> Ja, genau das is es.
>
>> Ok, das require kann ich weglassen, weil ich den Code schon manuell
>> inkludiert habe
>
> Du kannst es auch hinschreiben.

Nein.

> "require" checkt das selbst, indem es beim ersten Laden den Dateinamen
> in %INC aufnimmt und danach, wenn der Modulname als Key in %INC
> vorkommt, das nochmalige Laden unterläßt.

In dem Fall steht es aber noch nicht in %INC, require würde also
versuchen, das File zu laden, was aber nicht geht, weil das File gar
nicht existiert. Würde es existieren, könnte man es auch ganz normal
über use laden.

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: script und module zusammenfassen?

Ulli Horlacher wrote:
>
> von OO-Syntax krieg ich Pickel :-)

Du programmierst im Jahr 2007 noch nicht objektorientiert?
Das ist ja richtig gruselig :)

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: script und module zusammenfassen?

Peter J. Holzer:

>>> Ok, das require kann ich weglassen, weil ich den Code schon manuell
>>> inkludiert habe
> >
> > Du kannst es auch hinschreiben.
>
> Nein.
>
> > "require" checkt das selbst, indem es beim ersten Laden den Dateinamen
> > in %INC aufnimmt und danach, wenn der Modulname als Key in %INC
> > vorkommt, das nochmalige Laden unterl t.
>
> In dem Fall steht es aber noch nicht in %INC, require wrde also
> versuchen, das File zu laden, was aber nicht geht, weil das File gar
> nicht existiert. W rde es existieren, knnte man es auch ganz normal
> ber use laden.

Wieso existiert das File nicht? Es ging doch im Posting des OP
darum, den gesamten, durch "use", "require" oder "do" eingebundenen
Code in eine einzige Datei zu schreiben, um diese dann einfacher
verteilen zu können. Was macht es für einen Sinn, eine Datei laden
zu wollen, die nicht existiert?

Mein Posting bezog sich ja auch darauf, dass der Code, der das
"require" emuliert, auch einen %INC Hash entsprechend pflegt.
Übrigens führt auch "use" den Code für ein "require" durch und
erst dieses prüft nach, ob die zu ladende Datei bereits geladen ist.
Soweit hergeholt wäre das also gar nicht.

Auch der Aufruf von "import" wird bei einem "use" tatsächlich
durchgeführt, und durch die bereits erwähnte Sonderbehandlung
von "import" und "unimport" kommt es dennoch zu keiner Fehle-
rmeldung, wenn die Methode nicht existiert. Es handelt sich also
tatsächlich um ein vom Interpreter benötigtes Feature.

Hast du ein Problem mit dem Umlauten? Dein Posting kam bei
mir v llig ohne Umlaute an!

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: script und module zusammenfassen?

On 2007-10-22 06:23, Ferry Bolhar wrote:
> Peter J. Holzer:
>>>> Ok, das require kann ich weglassen, weil ich den Code schon manuell
>>>> inkludiert habe
>> >
>> > Du kannst es auch hinschreiben.
>>
>> Nein.
>>
>> > "require" checkt das selbst, indem es beim ersten Laden den Dateinamen
>> > in %INC aufnimmt und danach, wenn der Modulname als Key in %INC
>> > vorkommt, das nochmalige Laden unterl t.
>>
>> In dem Fall steht es aber noch nicht in %INC, require wrde also
>> versuchen, das File zu laden, was aber nicht geht, weil das File gar
>> nicht existiert. W rde es existieren, knnte man es auch ganz normal
>> ber use laden.
>
> Wieso existiert das File nicht?

Weil das Sinn der Übung ist.

> Es ging doch im Posting des OP darum, den gesamten, durch "use",
> "require" oder "do" eingebundenen Code in eine einzige Datei zu
> schreiben, um diese dann einfacher verteilen zu können.

Eben. Am Zielsystem existieren dann eben nicht mehr 'Foo.pm',
'Bar/Baz.pm' und so weiter, sondern nur mehr ein einziges Script.

> Was macht es für einen Sinn, eine Datei laden
> zu wollen, die nicht existiert?

Es macht eben keinen Sinn, darum weise ich darauf hin, dass das nicht
geht.


> Mein Posting bezog sich ja auch darauf, dass der Code, der das
> "require" emuliert, auch einen %INC Hash entsprechend pflegt.

Es mag sich darauf bezogen haben, aber reingeschrieben hast Du es nicht.
Deshalb habe ich darauf hingewiesen.

[ebenso bekanntes wie irrelevantes gelöscht]


> Hast du ein Problem mit dem Umlauten?

Nicht generell. Nur, wenn ich Deine Postings lese und darauf antworte.
Kannst Du bitte Deinen Newsreader so konfigurieren, dass er das charset
deklariert?

> Dein Posting kam bei mir v llig ohne Umlaute an!

Ja, bei Deinen Postings geht die automatische charset-Detection vom vim
in die Hose. Wenn ich das nicht manuell korrigiere (wie in diesem Fall),
verschicke ich ein Posting mit falsch deklariertem Charset.

hp


--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | hjp@hjp.at | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex