From kh at dartbase.com Tue Aug 2 03:41:58 2005 From: kh at dartbase.com (email) Date: Tue, 2 Aug 2005 06:41:58 -0400 Subject: [Vienna-pm] apache group membership feststellen? Message-ID: <200508021041.j72Afwq14835@dartbase.com> hi, ich will in einem CGI / mod_perl programm feststellen ob ein ueber BasicAuth (.htaccess) authentifizierter user member einer bestimmten gruppe ist (im .htaccess group file, nicht system groups), wobei es nicht unbedingt der fall ist dass der user aufgrund genau dieser gruppenzugehoerigkeit access bekommen hat. nun gibt es dafuer einige CPAN module wie HTTPD::GroupAdmin oder Apache::Htgroup, aber a) scheint keines dieser module bestandteil eines debian pakets zu sein und b) oeffnen und parsen anscheinend alle diese module das groupfile, was ja apache selbst eigentlich schon einmal im request erledigt hat ;-) meine frage nun: kennt jemand ein modul das das gewuenschte leistet und das mindestens a) erfuellt, und idealerweise auch ohne b) auskommt? thx + lg karlheinz From domm at zsi.at Tue Aug 2 09:28:06 2005 From: domm at zsi.at (Thomas Klausner) Date: Tue, 2 Aug 2005 18:28:06 +0200 Subject: [Vienna-pm] OT: Freundin sucht Job Message-ID: <20050802162805.GE25427@domm2.zsi.at> Hi! Meine Freundin hat Lehramt Werkerziehnung (Angewandten) und Deutsch studiert und letztes Jahr ihr Schulpraktikum gemacht. Es schaut zZ so aus, als ob sie keine Unterrichtsstunden bekommen wuerde. Deshalb sucht sie extrem dringend einen (20-Stunden-) Job. Idealerweise nicht allzu gehirnintensiv, weil sie nebenbei an ihrer Dissertation arbeitet. Wienweite Weiterleitung erwuenscht, Antworten noch mehr! Lebenslauf haengt dran... -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} -------------- next part -------------- A non-text attachment was scrubbed... Name: Barbara_Hollendonner_Lebenslauf.doc Type: application/msword Size: 33280 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050802/a8578454/Barbara_Hollendonner_Lebenslauf-0001.doc From hjp-vienna-pm-list at hjp.at Wed Aug 3 10:13:19 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Wed, 3 Aug 2005 19:13:19 +0200 Subject: [Vienna-pm] Dahut! :-) Message-ID: <20050803171319.GA24110@teal.hjp.at> http://dahut.pm.org/dahut_story.html hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050803/7ec01580/attachment.bin From horshack at lisa.franken.de Sat Aug 6 12:58:39 2005 From: horshack at lisa.franken.de (horshack@lisa.franken.de) Date: Sat, 6 Aug 2005 21:58:39 +0200 (CEST) Subject: [Vienna-pm] LWP um https zu holen Message-ID: Ich moechte per https Seiten aus dem Internet holen. Crypt::SSLeay ist installiert und das Holen der Seiten klappt auch solange ich keinen Proxyserver verwende. Dem Rechner selbst ist per IP-Adresse erlaubt den Proxyserver zu benutzen, mit einem Webbrowser klappt alles. http ohne Proxy: geht http mit Proxy: geht https ohne Proxy: geht https mit Proxy: 501-Problem wie beschrieben Die Fehlermeldung ist: Inhalt: Error while requesting URL https://www.gmx.net: 501 Not Implemented Seltsamerweise sagt der Proxy im Log das: 1123358064.773 3 10.1.1.63 TCP_DENIED/501 1387 GET https://www.gmx.net - NONE/- text/html Aber der selbe Rechner 10.1.1.63 kann problemlos https-Seiten holen. Kann es sein, dass ich mit https gar keine GET-Methode verwenden darf? Ich bin an echten Erfahrungen interessiert, bitte keine Mutmassungen. Ich mutmasse jetzt schon den ganzen Abend und weiss echt nicht mehr weiter. Das Programm: === use strict; use warnings; use LWP::UserAgent; use HTTP::Request; my $url = "https://www.gmx.net"; my $proxy = "http://proxy.rosi13.de:3128/"; my $ua = LWP::UserAgent->new; $ua->proxy( "https", $proxy ); my $request = HTTP::Request->new( GET => $url ); # $content="" when Methode = CONNECT # my $request = HTTP::Request->new( CONNECT => $url ); my $response = $ua->request($request); my $content; if ( $response->is_error() ) { $content = sprintf( "Error while requesting URL $url: %s\n", $response->status_line ); } else { $content = $response->content(); } print "Inhalt: " . $content, "\n"; === Danke! Richard Lippmann --- Richard Lippmann, Nuernberg, Germany Private: http://lena.franken.de Business with Findus Internet-OPAC: http://www.findus-internet-opac.de From mjy at geizhals.at Sat Aug 6 16:44:57 2005 From: mjy at geizhals.at (Marinos Yannikos) Date: Sun, 07 Aug 2005 01:44:57 +0200 Subject: [Vienna-pm] LWP um https zu holen In-Reply-To: References: Message-ID: <42F54B79.4060909@geizhals.at> horshack at lisa.franken.de wrote: > Kann es sein, dass ich mit https gar keine GET-Methode verwenden darf? Nein, das kann nicht sein. > Ich > bin an echten Erfahrungen interessiert, bitte keine Mutmassungen. Ich > mutmasse jetzt schon den ganzen Abend und weiss echt nicht mehr weiter. Es geht definitiv mit LWP und einem Proxy. Meine "Mutma?ung" ist, da? dein Proxy kein SSL unterst?tzt oder nicht daf?r konfiguriert ist (dazu hast du dich auch nicht ge?u?ert). Zum Testen (mit bourne-shell): # https_proxy=http://proxy.rosi13.de:3128/ GET https://www.gmx.net Wenn das funktioniert, unterst?tzen sowohl LWP als auch der Proxy SSL und dein Script ist wohl buggy (siehe dann z.B. vi `which GET`). Wenn das nicht funktioniert, dann probier' mal # https_proxy=http://proxy.rosi13.de:3128/ wget -O - https://www.gmx.net Wenn das funktioniert, ist deine LWP/SSL-Installation nicht vollst?ndig und der Proxy ist OK. Wenn es auch nicht funktioniert, ist wohl der Proxy schuld. MfG, -mjy From horshack at lisa.franken.de Sun Aug 7 01:15:31 2005 From: horshack at lisa.franken.de (horshack@lisa.franken.de) Date: Sun, 7 Aug 2005 10:15:31 +0200 (CEST) Subject: [Vienna-pm] LWP um https zu holen In-Reply-To: References: Message-ID: Danke fuer die Antworten. Es hatte wirklich mit dem CONNECT/GET zu tun. Beim Holen einer Seite mit https MUSS DIE UMGEBUNGSVARIABLE HTTPS_PROXY gesetzt sein. Die Umgebungsvariable, die Methode $ua->proxy hilft offensichtlich nichts. Wenn das getan ist verwendet LWP die Methode CONNECT (sagt mein Proxylog) und alles funktioniert. Ich war der festen Ueberzeugung, dass $ua->proxy und $ENV{HTTPS_PROXY} das selbe bewirken. Das ist ganz offensichtlich nicht der Fall. Die Ueberlegungen um CONNECT und GET haben mir schon geholfen dann in Google das Suchergebnis stark einzugrenzen. Danke sehr! Richard Lippmann --- Richard Lippmann, Nuernberg, Germany ?Private: http://lena.franken.de Business with Findus Internet-OPAC: http://www.findus-internet-opac.de On Sat, 6 Aug 2005 horshack at lisa.franken.de wrote: > Ich moechte per https Seiten aus dem Internet holen. Crypt::SSLeay ist > installiert und das Holen der Seiten klappt auch solange ich keinen > Proxyserver verwende. Dem Rechner selbst ist per IP-Adresse erlaubt den > Proxyserver zu benutzen, mit einem Webbrowser klappt alles. > > http ohne Proxy: geht > http mit Proxy: geht > https ohne Proxy: geht > https mit Proxy: 501-Problem wie beschrieben > > Die Fehlermeldung ist: > Inhalt: Error while requesting URL https://www.gmx.net: 501 Not > Implemented > > Seltsamerweise sagt der Proxy im Log das: > 1123358064.773 3 10.1.1.63 TCP_DENIED/501 1387 GET > https://www.gmx.net - NONE/- text/html > > Aber der selbe Rechner 10.1.1.63 kann problemlos https-Seiten holen. > > Kann es sein, dass ich mit https gar keine GET-Methode verwenden darf? Ich > bin an echten Erfahrungen interessiert, bitte keine Mutmassungen. Ich > mutmasse jetzt schon den ganzen Abend und weiss echt nicht mehr weiter. > > Das Programm: > === > use strict; > use warnings; > use LWP::UserAgent; > use HTTP::Request; > > my $url = "https://www.gmx.net"; > my $proxy = "http://proxy.rosi13.de:3128/"; > > my $ua = LWP::UserAgent->new; > $ua->proxy( "https", $proxy ); > my $request = HTTP::Request->new( GET => $url ); > # $content="" when Methode = CONNECT > # my $request = HTTP::Request->new( CONNECT => $url ); > > my $response = $ua->request($request); > my $content; > if ( $response->is_error() ) { > $content = sprintf( "Error while requesting URL $url: %s\n", > $response->status_line ); > } > else { > $content = $response->content(); > } > > print "Inhalt: " . $content, "\n"; > === > > Danke! > Richard Lippmann > > > --- > Richard Lippmann, Nuernberg, Germany > Private: http://lena.franken.de > Business with Findus Internet-OPAC: http://www.findus-internet-opac.de > > > _______________________________________________ > Vienna-pm mailing list > Vienna-pm at pm.org > http://mail.pm.org/mailman/listinfo/vienna-pm > > From hjp-vienna-pm-list at hjp.at Wed Aug 10 09:36:53 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Wed, 10 Aug 2005 18:36:53 +0200 Subject: [Vienna-pm] Garbage-Collection Message-ID: <20050810163653.GA15186@teal.hjp.at> Ich habe ein kleines Script, das ein relativ gro?es Hash-of-Hash-of-Array erzeugt. Der Perl-Prozess w?chst dabei auf ca. 1.3 GB (wobei mir die letzten 0.4 GB auch nicht ganz klar sind, denn da wird nur mehr ausgegeben, und Autovivification kann da IMHO nicht mehr auftreten, aber egal). RAM hat meine Workstation nur 512 MB. Trotzdem l?uft das Script relativ flott durch (ca. 10 Minuten), bis, ja, bis es eigentlich fertig ist. Und dort bleibt es dann stehen und die Kiste swappt ganz f?rchterlich vor sich hin. Ich vermute, dass der Garbage-Collector versucht, die vielen, vielen kleinen Skalare einzusammeln. Aber warum braucht das so lange? Die Datenstruktur hat keine Kreise, der Perl-GC ist meines Wissens reference-count-based, mir k?me vor, das sollte sich in einem Durchlauf durch den Tree erledigen lassen. Und warum macht es keinen Unterschied, wenn ich das Hash schon vorher mittels for my $t (keys %$tp) { delete $tp->{$t}; } explizit zerst?re? hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050810/7a60f9ea/attachment.bin From mjy at geizhals.at Wed Aug 10 09:53:23 2005 From: mjy at geizhals.at (Marinos Yannikos) Date: Wed, 10 Aug 2005 18:53:23 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <20050810163653.GA15186@teal.hjp.at> References: <20050810163653.GA15186@teal.hjp.at> Message-ID: <42FA3103.3040800@geizhals.at> Peter J. Holzer schrieb: > bis, ja, bis es > eigentlich fertig ist. Und dort bleibt es dann stehen und die Kiste > swappt ganz f?rchterlich vor sich hin. Klingt so, als w?rde es die ?brigen ~0.8gb erst einmal reinswappen, um sie dann freizugeben (dort sind ja wohl auch Daten zu manipulieren w?hren des GC). > for my $t (keys %$tp) { > delete $tp->{$t}; > } Wieviele keys sind das denn so? MfG, -mjy From hjp-vienna-pm-list at hjp.at Wed Aug 10 11:19:08 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Wed, 10 Aug 2005 20:19:08 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <42FA3103.3040800@geizhals.at> References: <20050810163653.GA15186@teal.hjp.at> <42FA3103.3040800@geizhals.at> Message-ID: <20050810181907.GA18805@teal.hjp.at> On 2005-08-10 18:53:23 +0200, Marinos Yannikos wrote: > Peter J. Holzer schrieb: > > bis, ja, bis es > > eigentlich fertig ist. Und dort bleibt es dann stehen und die Kiste > > swappt ganz f?rchterlich vor sich hin. > > Klingt so, als w?rde es die ?brigen ~0.8gb erst einmal reinswappen, um > sie dann freizugeben (dort sind ja wohl auch Daten zu manipulieren > w?hren des GC). Zweifellos. Aber die Daten muss er ja wohl beim Anlegen, Bearbeiten und Ausgeben des Trees auch angegriffen haben und das geht deutlich schneller. Es scheint also so zu sein, dass er beim Aufr?umen die Daten entweder in sehr zuf?lliger Reihenfolge angreift (was zu wildem Thrashen f?hren w?rde) oder mehrfach. Das widerspricht aber dem, was ich glaubte, ?ber den Perl-Garbage-Collector zu wissen. Ich dachte, das w?rde einfach nur Reference-Counts verwalten und jedes Objekt sofort freigeben, wenn der Reference-Count auf 0 f?llt. Daher auch mein Experiment, die Elemente des Hashs explizit zu entfernen. Mit jedem Element, das ich entferne, m?sste ein Teilbaum gc't werden. Wenn das Hash am Schluss leer ist, gibt es auch keine anonymen Arrays und Hashes mehr und das Programm m?sste sofort terminieren - ist aber nicht so. (Jetzt ist es ?brigens gerade fertiggeworden - nach gut 3 Stunden) > > for my $t (keys %$tp) { > > delete $tp->{$t}; > > } > > Wieviele keys sind das denn so? Ca. 250_000. Jeder Value ist wieder ein Hashref auf ein anonymes Hash mit 27 Keys (in allen die gleichen), deren Values Arrayrefs auf Arrays mit 3 Zahlen (etliche davon undef) sind. Also 250000 Hashes, 6.75 Mio Arrays, und sch?tzungsweise an die 20 Millionen Skalare. hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050810/df4870bb/attachment.bin From hjp-vienna-pm-list at hjp.at Wed Aug 10 11:42:54 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Wed, 10 Aug 2005 20:42:54 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <20050810181907.GA18805@teal.hjp.at> References: <20050810163653.GA15186@teal.hjp.at> <42FA3103.3040800@geizhals.at> <20050810181907.GA18805@teal.hjp.at> Message-ID: <20050810184254.GB18805@teal.hjp.at> On 2005-08-10 20:19:08 +0200, Peter J. Holzer wrote: > (Jetzt ist es ?brigens gerade fertiggeworden - nach gut 3 Stunden) Irrtum, es l?uft noch. Ist nur offenbar kurzfristig im top soweit runtergerutscht, dass ich es nicht mehr gesehen habe. hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050810/0b1aaab6/attachment.bin From lt at toetsch.at Wed Aug 10 13:55:30 2005 From: lt at toetsch.at (Leopold Toetsch) Date: Wed, 10 Aug 2005 22:55:30 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <20050810163653.GA15186@teal.hjp.at> References: <20050810163653.GA15186@teal.hjp.at> Message-ID: On Aug 10, 2005, at 18:36, Peter J. Holzer wrote: > Ich habe ein kleines Script, das ein relativ gro?es > Hash-of-Hash-of-Array erzeugt. Der Perl-Prozess w?chst dabei auf ca. > 1.3 > GB (wobei mir die letzten 0.4 GB auch nicht ganz klar sind, denn da > wird > nur mehr ausgegeben, und Autovivification kann da IMHO nicht mehr > auftreten, aber egal). Wenn trotz explizitem delete noch Speicher verbraucht wird (und das Programm am Ende offsensichtlich heftigst mit aufrauemen beschaeftigt ist) kann ich mir nur 2 Dinge vorstellen: a) die "Ausgabe" referenziert noch scalars. D.h. durch substr, regexen oder was immer werden scalars der Eingabe referneziert. b) ein bug in perl > hp leo From hjp-vienna-pm-list at hjp.at Thu Aug 11 00:02:58 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Thu, 11 Aug 2005 09:02:58 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: References: <20050810163653.GA15186@teal.hjp.at> Message-ID: <20050811070258.GC18805@teal.hjp.at> On 2005-08-10 22:55:30 +0200, Leopold Toetsch wrote: > On Aug 10, 2005, at 18:36, Peter J. Holzer wrote: > >Ich habe ein kleines Script, das ein relativ gro?es > >Hash-of-Hash-of-Array erzeugt. Der Perl-Prozess w?chst dabei auf ca. > >1.3 GB (wobei mir die letzten 0.4 GB auch nicht ganz klar sind, denn > >da wird nur mehr ausgegeben, und Autovivification kann da IMHO nicht > >mehr auftreten, aber egal). > > Wenn trotz explizitem delete noch Speicher verbraucht wird (und das > Programm am Ende offsensichtlich heftigst mit aufrauemen beschaeftigt > ist) kann ich mir nur 2 Dinge vorstellen: > a) die "Ausgabe" referenziert noch scalars. D.h. durch substr, regexen > oder was immer werden scalars der Eingabe referneziert. In dem Fall scheint eher die "Eingabe" schuld zu sein: Das Script hat urspr?nglich aus mehreren SQLite-Datenbanken gelesen. Nachdem ich testweise die interessanten Teile in Textfiles dedumpt und das Script so umgeschrieben hatte, dass es aus den Textfiles liest, ist das Problem verschwunden. Ich vermute daher, dass hier irgendwo Referenzen ?brigbleiben. Habe zwar versucht, mittels while (my ($token, $count) = $sth->fetchrow_array) { my $tkcnt = $count+0; # <---- my $tkprp = $tkcnt/$msgcnt; $tp->{$token . ""}{$corpus_name} = [ $tkprp, $tkcnt ]; # ^^^^^^^^^^^ die Verwendung von Kopien zu erzwingen aber das scheint nichts gefruchtet zu haben. Interessanterweise ist ein "manuelles" Abbauen des Hashes mittels delete der einzelnen Elemente schneller ist als sich auf die Garbage-Collection beim exit zu verlassen. hp PS: Die DBD::SQLite-Version, die ich hier installiert habe, ist ca. 1.5 Jahre alt (0.31). Die aktuelle (1.09) wirft bei einem select, das 0 Rows liefert, eine Exception :-(. hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050811/37aaa717/attachment.bin From gooly at gmx.at Thu Aug 11 01:54:59 2005 From: gooly at gmx.at (Carl A. Schreiber) Date: Thu, 11 Aug 2005 10:54:59 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <20050811070258.GC18805@teal.hjp.at> References: <20050810163653.GA15186@teal.hjp.at> <20050811070258.GC18805@teal.hjp.at> Message-ID: <200508111054.59709.gooly@gmx.at> Peter, aus meinem kleinen Erfahrungsschatzk?stchen.. > > Interessanterweise ist ein "manuelles" Abbauen des Hashes mittels delete > der einzelnen Elemente schneller ist als sich auf die Garbage-Collection > beim exit zu verlassen. > Ich hatte mal ein immer langsamer werdendes script, dass einen immer gr??er werdendes array aufbaute. Das konnte ich ziemlich bescheunigen, in dem ich an Stelle eines arrays (push bzw neues hash element) alles an einen string klebte und am Ende (dazwischen brauchte ich die Dinge nicht) mit split wieder in ein array splittete. Ich kann mir vorstellen, das diese Art auch speichersparsamer ist! Nimm halt geeignete delimiter zB $delim = "\021" ist der vertical Delimiter, der wird praktisch nie verwendet! Das st?ndige Umkopieren eines immer gr??er werdenden array kostete ziemlich viel Zeit in Perl! Ein Array (== Hash) wird in Perl ja mit eine best. Gr??e angelegt und wenn die Gr??e ?berschritten wird es in einen g??eren (doppelt?) umkopiert. Mit delete kannst Du nun wahrscheinlich genau diese wiederholten 'Schwellen?berschreitungen' hoch, runter,hoch, runter, .. vermeiden, desshalb ist's wahrscheinlich schneller. hih (hope it helps) Calli From patrick at pantheon.at Thu Aug 11 03:24:18 2005 From: patrick at pantheon.at (Patrick Meidl) Date: Thu, 11 Aug 2005 11:24:18 +0100 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <20050810181907.GA18805@teal.hjp.at> References: <20050810163653.GA15186@teal.hjp.at> <42FA3103.3040800@geizhals.at> <20050810181907.GA18805@teal.hjp.at> Message-ID: <20050811102418.GL2116@lektor.homelinux.net> On Wed, Aug 10 2005, Peter J. Holzer wrote: > Das widerspricht aber dem, was ich glaubte, ?ber den > Perl-Garbage-Collector zu wissen. > > Ich dachte, das w?rde einfach nur Reference-Counts verwalten und jedes > Objekt sofort freigeben, wenn der Reference-Count auf 0 f?llt. das ist richtig. ein gotcha, ueber das ich einmal gestolpert bin, ist, dass der perl garbage collector einmal allozierten speicher erst beim beenden des scripts wieder ans system zurueckgibt (er kann aber intern fuer andere daten verwendet werden). wenn du also deine riesige data structure loescht, ist der memory footprint des scripts nachher immer noch derselbe. patrick -- Patrick Meidl ........................... +44-7770-526961 (mobile) 20 Guest Road ........................... +44-1223-514058 (home) Cambridge CB1 2AL ....................... patrick at pantheon.at England, UK ............................. http://pmeidl.homelinux.net/ -- From hjp-vienna-pm-list at hjp.at Thu Aug 11 04:34:10 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Thu, 11 Aug 2005 13:34:10 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <20050811102418.GL2116@lektor.homelinux.net> References: <20050810163653.GA15186@teal.hjp.at> <42FA3103.3040800@geizhals.at> <20050810181907.GA18805@teal.hjp.at> <20050811102418.GL2116@lektor.homelinux.net> Message-ID: <20050811113410.GA27671@teal.hjp.at> On 2005-08-11 11:24:18 +0100, Patrick Meidl wrote: > On Wed, Aug 10 2005, Peter J. Holzer wrote: > > > Das widerspricht aber dem, was ich glaubte, ?ber den > > Perl-Garbage-Collector zu wissen. > > > > Ich dachte, das w?rde einfach nur Reference-Counts verwalten und jedes > > Objekt sofort freigeben, wenn der Reference-Count auf 0 f?llt. > > das ist richtig. ein gotcha, ueber das ich einmal gestolpert bin, ist, > dass der perl garbage collector einmal allozierten speicher erst beim > beenden des scripts wieder ans system zurueckgibt (er kann aber intern > fuer andere daten verwendet werden). wenn du also deine riesige data > structure loescht, ist der memory footprint des scripts nachher immer > noch derselbe. Ja, das ist das traditionelle Verhalten von Unix-malloc. Die glibc hat allerdings ein anderes Verhalten: Gro?e Memory-Bl?cke (?ber 128 kB, IIRC) werden sofort ans OS zur?ckgegeben, kleine werden "recycelt" und nur zur?ckgegeben, wenn es sich auszahlt. Perl bringt noch eine eigene Malloc-Implementation mit, die man optional verwenden kann - m?glicherweise verh?lt sich die so wie das Unix-malloc. Bei den beiden perl-Builds, die ich f?r die Tests verwendet habe ist allerdings laut "perl -V" usemymalloc=n - somit sollte da eigentlich das glibc-Verhalten zum Vorschein kommen. Konnte ich in diesem Fall nicht beobachten, aber da das sehr von der Reihenfolge der Allokationen und Deallokationen abh?ngt, wundert mich das nicht. Noch eine kleine Beobachtung: Folgendes Progr?mmchen braucht konstant 26 MB RAM: ---8<------8<------8<------8<------8<------8<------8<------8<------8<--- #!/usr/bin/perl use warnings; use strict; my $s; for ('A' .. 'Z') { $s = $_ x 10_000_000; print "$_\n"; sleep 10; $s = "x"; print "x\n"; sleep 10; } --->8------>8------>8------>8------>8------>8------>8------>8------>8--- Wenn man die Schleife aber entrollt: --->8------>8------>8------>8------>8------>8------>8------>8------>8--- #!/usr/bin/perl use warnings; use strict; my $s; # A $s = "A" x 10_000_000; print "A\n"; sleep 10; $s = "x"; print "x\n"; sleep 10; # B $s = "B" x 10_000_000; print "B\n"; sleep 10; $s = "x"; print "x\n"; sleep 10; # C [...] --->8------>8------>8------>8------>8------>8------>8------>8------>8--- Dann steigt der Speicherverbrauch mit jeder Zuweisung eines "gro?en" Strings um 10 MB an. (perl 5.8.3 und 5.8.6 auf Linux) hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050811/d9d2f160/attachment.bin From hjp-vienna-pm-list at hjp.at Thu Aug 11 05:13:16 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Thu, 11 Aug 2005 14:13:16 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <200508111054.59709.gooly@gmx.at> References: <20050810163653.GA15186@teal.hjp.at> <20050811070258.GC18805@teal.hjp.at> <200508111054.59709.gooly@gmx.at> Message-ID: <20050811121316.GB27671@teal.hjp.at> On 2005-08-11 10:54:59 +0200, Carl A. Schreiber wrote: > > Interessanterweise ist ein "manuelles" Abbauen des Hashes mittels delete > > der einzelnen Elemente schneller ist als sich auf die Garbage-Collection > > beim exit zu verlassen. > > > Ich hatte mal ein immer langsamer werdendes script, dass einen immer gr??er > werdendes array aufbaute. Das konnte ich ziemlich bescheunigen, in dem ich an > Stelle eines arrays (push bzw neues hash element) alles an einen string > klebte und am Ende (dazwischen brauchte ich die Dinge nicht) mit split wieder > in ein array splittete. Ich kann mir vorstellen, das diese Art auch > speichersparsamer ist! Ja, die vielen kleinen Objekte, die Perl einzeln verwaltet, bedeuten nat?rlich einiges an Overhead. Ich sch?tze, dass ich in C nur ca. 200MB statt 1.3 GB RAM gebraucht h?tte :-). Prinzipiell fallen mir nat?rlich schon ein paar Methoden ein, wie man in dem Fall Speicher h?tte sparen k?nnen: Z.B. war die Anzahl der Keys in der mittleren Ebene beim Programmstart bekannt. Statt $tp->{$token}{$corpus_name}[$idx] h?tte ich daher auch $tp[(($token_idx * $nr_of_corpora) + $corpus_idx) * 3 + $idx] schreiben k?nnen und in zwei anderen Hashes ein Mapping von $token bzw. $corpus_name auf die entprechenden numerischen Indices mitf?hren k?nnen. Wenn man das Array gleich in einer plausiblen Gr??e anlegt, muss es auch nicht allzu oft vergr??ert werden. Und dann gibt es ja noch ein paar Module f?r das Rechnen mit gro?en Matrizen, damit sollte man dann in ?hnliche Bereiche wie bei C kommen. Aber das war ja eigentlich nicht mein Problem. > Nimm halt geeignete delimiter zB $delim = "\021" ist > der vertical Delimiter, der wird praktisch nie verwendet! > > Das st?ndige Umkopieren eines immer gr??er werdenden array kostete ziemlich > viel Zeit in Perl! > > Ein Array (== Hash) wird in Perl ja mit eine best. Gr??e angelegt und wenn die > Gr??e ?berschritten wird es in einen g??eren (doppelt?) umkopiert. > Mit delete kannst Du nun wahrscheinlich genau diese wiederholten > 'Schwellen?berschreitungen' hoch, runter,hoch, runter, .. vermeiden, desshalb > ist's wahrscheinlich schneller. Nein, bei der Garbage-Collection geht's ja nur runter, nie rauf. Und die Objekte werden als ganzes freigegeben: Wenn z.B. ein Hash mit 250000 Elementen out-of-scope geht, dann muss zwar f?r jedes Element der Reference-Counter dekrementiert und gepr?ft werden, aber das Hash an sich wird als ganzes freigegeben: Es kann nicht passieren, dass es mit 100000 Elementen weiterexistiert. Ich vermute dass GC langsamer ist als manuelles Abbauen, weil die Reihenfolge anders ist: Beim manuellen Abbauen verschwindet immer ein Teilbaum auf einmal: Das sind Daten, die auch gemeinsam angelegt wurden und daher wahrscheinlich nahe beisammen im Memory liegen: Da muss wenig geswappt werden. Das GC kommt es darauf an, ob die Reference-Counts depth-first rekursiv abgearbeitet werden oder breadth-first: Im letzteren Fall sind die Memory-Zugriffe zumindest im Fall meines Scripts ziemlich zuf?llig: Es muss ziemlich viel geswappt werden. hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050811/d0b7f692/attachment.bin From lt at toetsch.at Thu Aug 11 06:04:29 2005 From: lt at toetsch.at (Leopold Toetsch) Date: Thu, 11 Aug 2005 15:04:29 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <20050811113410.GA27671@teal.hjp.at> References: <20050810163653.GA15186@teal.hjp.at> <42FA3103.3040800@geizhals.at> <20050810181907.GA18805@teal.hjp.at> <20050811102418.GL2116@lektor.homelinux.net> <20050811113410.GA27671@teal.hjp.at> Message-ID: <42FB4CDD.9000401@toetsch.at> Peter J. Holzer wrote: > Ja, das ist das traditionelle Verhalten von Unix-malloc. Die glibc hat > allerdings ein anderes Verhalten: Gro?e Memory-Bl?cke (?ber 128 kB, > IIRC) werden sofort ans OS zur?ckgegeben, kleine werden "recycelt" und > nur zur?ckgegeben, wenn es sich auszahlt. Yep. Siehe auch $glibc_src/malloc.c: #define DEFAULT_MMAP_THRESHOLD (128 * 1024) D.h. perl kann zwar Speicher freigeben, aber es h?ngt von der libc ab, ob der Speicher tats?chlich f?r andere Anwendungen frei verf?gbar wird. Bei kleinen Bl?cken ist das nie der Fall, bei gro?en *kann* der Speicher verf?gbar werden, wenn die Fragmentierung das zul??t. > Noch eine kleine Beobachtung: > Wenn man die Schleife aber entrollt: > $s = "A" x 10_000_000; > # B > $s = "B" x 10_000_000; > Dann steigt der Speicherverbrauch mit jeder Zuweisung eines "gro?en" > Strings um 10 MB an. Das ist nicht so verwunderlich. In Parrot w?rde das so ausschauen: $S0 = repeat "A", 10000000 $P0 = new .String $P0 = $S0 store_lex -1, "$s", $P0 $P0 = "x" $S1 = repeat "B", 10000000 $P1 = new .String $P1 = $S1 store_lex -1, "$s", $P1 $P1 = "x" Nun kommt es darauf an, ob der Registerallocator die tempor?ren Strings ($S0, $S1) oder ($P0, $P1) an separate Register zuweist, oder ob die Register wiederverwendet werden. Nur in letzterem Fall w?rde der Speicherverbrauch nicht ansteigen (tats?chlich werden die Register wiederverwendet, wenn sie sp?ter nicht mehr referenziert sind). In Perl schaut das aber anders aus. Die Ausgabe von: $ perl -MO=Concise,-exec hjp.pl ... repeat[t2] .. ... repeat[t7] ... scheint anzudeuten, da? die tempor?ren Strings verschieden sind. Nun sollte man annehmen, da? der Refcount des tempor?ren Strings am Stack nach "Verbrauch" des Temps 0 werden sollte. Aber hier schl?gt eine "Optimierung" von perl zu: Die SVs am Stack werden nicht refgecounted, d.h. ein SvREFCNT_dec() findet erst in Perl_leave_scope() statt. Allerdings do { blabla; }; oder oder if (1) {} hilft auch nicht. D.h. tempor?re Speicherfresser sollten in eigene Unterprogramme ausgelagert werden. > hp leo From areibens at cpan.org Thu Aug 11 18:53:36 2005 From: areibens at cpan.org (Alfred Reibenschuh) Date: Fri, 12 Aug 2005 03:53:36 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <42FB4CDD.9000401@toetsch.at> References: <20050810163653.GA15186@teal.hjp.at> <42FA3103.3040800@geizhals.at> <20050810181907.GA18805@teal.hjp.at> <20050811102418.GL2116@lektor.homelinux.net> <20050811113410.GA27671@teal.hjp.at> <42FB4CDD.9000401@toetsch.at> Message-ID: On Thu, 11 Aug 2005 15:04:29 +0200, you wrote: ... >scheint anzudeuten, da? die tempor?ren Strings verschieden sind. Nun >sollte man annehmen, da? der Refcount des tempor?ren Strings am Stack >nach "Verbrauch" des Temps 0 werden sollte. Aber hier schl?gt eine >"Optimierung" von perl zu: Die SVs am Stack werden nicht refgecounted, >d.h. ein SvREFCNT_dec() findet erst in Perl_leave_scope() statt. > >Allerdings > > do { > blabla; > }; > >oder oder if (1) {} hilft auch nicht. D.h. tempor?re Speicherfresser >sollten in eigene Unterprogramme ausgelagert werden. jetzt versteh ich endlich das speicherverhalten bei grossen PDFs thx cheers, -- __ _ / _|_ __ ___ __| | ___ unix, linux, freebsd | |_| '__/ _ \/ _` |/ _ \ jpeg, png, gif, ppm | _| | | __/ (_| | (_) | apache, perl, php, mysql |_| |_| \___|\__,_|\___/ pdf, ps, abw, html, pod From pilsl at goldfisch.at Sun Aug 14 15:07:32 2005 From: pilsl at goldfisch.at (peter pilsl) Date: Mon, 15 Aug 2005 00:07:32 +0200 Subject: [Vienna-pm] Garbage-Collection In-Reply-To: <20050810163653.GA15186@teal.hjp.at> References: <20050810163653.GA15186@teal.hjp.at> Message-ID: <42FFC0A4.2020207@goldfisch.at> Peter J. Holzer wrote: > einzusammeln. Aber warum braucht das so lange? Die Datenstruktur hat > keine Kreise, der Perl-GC ist meines Wissens reference-count-based, mir > k?me vor, das sollte sich in einem Durchlauf durch den Tree erledigen > lassen. nur am rand zum thema passend: die perl garbage-collection arbeitet keinesfalls perfekt. es treten immer wieder bugs auf, die man dann beim programmieren unter mod_perl oder bei applikationen mit grossen datenmengen entdeckt. zB hat die garbage-collection bis weit in 5.6 konstrukte nicht zerst?rt, die via eval referenzen auf methoden erhalten haben. dazu kommen die bereits diskutierten probleme, was die unterliegenden libs unter garbarge-collection eigentlich verstehen und wann der speicher dann f?r andere prozesse wieder verf?gbar wird. Ich verbringe also immer noch gelegentlich ein hide&seek-spiel mit memleaks unter mod_perl. Immer wieder spannend ;) lgp ps: morgen um diese zeit bin ich aber schon am strand in valun ;) From domm at zsi.at Thu Aug 18 09:18:33 2005 From: domm at zsi.at (Thomas Klausner) Date: Thu, 18 Aug 2005 18:18:33 +0200 Subject: [Vienna-pm] Fwd: JOB: Mitarbeiter gesucht (in Muenchen) Message-ID: <20050818161833.GB5766@domm2.zsi.at> Ist zwar in Muenchen, aber wer weiss ----- Forwarded message from Jens Kl?cker ----- From: Jens Kl?cker To: perl-mongers at 42.org Subject: Mitarbeiter gesucht Date: Thu, 18 Aug 2005 17:33:41 +0200 Hallo zusammen, zur Verst?rkung unseres Teams in M?nchen suchen wir eine(n) Entwickler(in) zur Festanstellung. Hauptaufgabe ist die Weiterentwicklung eines Portalsystems im E-Learning-Bereich, welches auf Apache::ASP / mod_perl basiert. Voraussetzung hierf?r sind fundierte Kenntnisse in folgenden Bereichen: - Objektorientierte Softwareentwicklung mit Perl - XML, DOM, XSLT etc. (am besten bereits unter Verwendung von XML::LibXML und XML::LibXSLT) - SQL, insbesondere MySQL - I18N von Softwaresystemen Von Vorteil, aber keine zwingende Voraussetzung, sind Kenntnisse in - Entwicklung von mod_perl-Handlern - Apache::ASP - Template-Toolkit - SOAP::Lite - PHP (ja, richtig gelesen) Die Entwicklung selber erfolgt unter Linux, der Betrieb der meisten Systeme unter FreeBSD. Ein sicherer Umgang mindestens mit Linux in der t?glichen Arbeit ist unbedingte Voraussetzung. Die Stelle ist ab sofort zu besetzen, Bewerbungen schickt ihr am besten an mich. Informationen zur Firma gibt's unter http://www.ets-online.de Viele Gr??e -- Jens Kl?cker ? e/t/s didactic media Bodenseestra?e 4, 81241 M?nchen Tel: (0 89) 82 04 06 18 ? Fax: (0 89) 82 04 06 10 ----- End forwarded message ----- -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From domm at zsi.at Mon Aug 22 06:28:49 2005 From: domm at zsi.at (Thomas Klausner) Date: Mon, 22 Aug 2005 15:28:49 +0200 Subject: [Vienna-pm] [ug@oreilly.de: Newsletter des O'Reilly UserGroup-Programms, 08/05] Message-ID: <20050822132849.GD4901@domm2.zsi.at> Viele Perl-Buecher, diesesmal! Bei Interesse mail an mich ----- Forwarded message from O'Reilly Verlag ----- To: user_groups at oreilly.de From: O'Reilly Verlag Subject: Newsletter des O'Reilly UserGroup-Programms, 08/05 Date: Thu, 18 Aug 2005 10:31:22 +0200 (CEST) ____________________________________________________ O'Reilly UserGroup News -- für UserGroup-Vertreter August 2005 ____________________________________________________ Allgemeines ------------ Bitte weisen Sie Ihre Mitglieder auf die Möglichkeit hin, Exemplare unserer Bücher zur Besprechung zu erhalten. Sie können die Bücher für die Interessenten formlos per E-Mail anfordern. Nennen Sie dazu bitte die ISBN und die gewünschte Lieferanschrift. Bitte senden Sie uns Belege Ihrer Besprechungen. Hinweise zum Verfassen von Rezensionen finden Sie hier: http://www.oreilly.de/ug/rezensionen.html Kontakt -------- Sie haben Feedback, Wünsche und Anregungen? Wir freuen uns, von Ihnen zu hören! E-Mail: ug at oreilly.de ____________________________________________________ O'Reilly UserGroup News -- für UserGroup-Mitglieder August 2005 ____________________________________________________ Besuchen Sie die EuroOSCON in Amsterdam! Bitte beachten Sie folgenden Termin: Bei einer Anmeldung bis zum 29. August können Sie bis zu 400 Euro sparen! Eine zusätzliche Ermässigung von 15% gibt es für alle Mitglieder einer UserGroup! Verwenden Sie bitte den folgenden Buchungscode: euos05usrg Mehr Informationen finden Sie hier: http://conferences.oreillynet.com/pub/w/41/register.html --------------------------------------------------------------------- Tim O'Reillys Antwort auf die Frage: "Is Perl still relevant?" finden Sie hier: http://www.oreillynet.com/pub/a/oreilly/ask_tim/2004/perl_0707.html ---------------------------------------------------------------------- Deutschsprachige Neuerscheinungen (Details s.u.) ---------------------------------- 1. Linux Netzwerk-Handbuch 2. Mit Open Source Tools Spam und Viren bekämpfen Englischsprachige Neuerscheinungen (Details s.u.) ----------------------------------- 1. Perl Best Practices 2. Perl Testing: A Developer's Notebook 3. Learning Perl, 4th edition 4. Advanced Perl Programming ----------------------------------- Deutschsprachige Neuerscheinungen ----------------------------------- 1. Linux Netzwerk-Handbuch 2. Mit Open Source Tools Spam und Viren bekämpfen 1. Linux Netzwerk-Handbuch, 3. Auflage ======================================= Tony Bautts, Terry Dawson & Gregor N. Purdy Deutsche Übersetzung von Kathrin Lichtenberg 3. Auflage Juli 2005 ISBN 3-89721-414-8 382 Seiten, EUR 38.00 Dieser Klassiker unseres Programms liegt nun in der 3., überarbeiteten und erweiterten Auflage vor und bietet Ihnen das nötige Rüstzeug, das Sie für die Einrichtung und Administration von Linux-Netzwerken brauchen. Zunächst vermitteln Ihnen die Autoren die Netzwerk-Grundlagen und widmen sich ausgiebig Themen wie TCP/IP und PPP. Weitere Kapitel beschäftigen sich mit der Linux-Funktionalität zum Einrichten einer Firewall, IP-Accounting und Masquerading. Als weit verbreitete Nutzung von Netzwerkanbindungen darf das Thema E-Mail mit sendmail und IMAP-Servern natürlich nicht fehlen. Schließlich befasst sich das Buch mit gleichermaßen gängigen und leistungsfähigen Diensten wie Apache, Samba und OpenLDAP und behandelt sie unter dem Gesichtspunkt anfallender Administrationsaufgaben. Auch Technologien wie Wireless Networking und IPv6 werden eingehend berücksichtigt. Eine ausführliche Beschreibung finden Sie hier: http://www.oreilly.de/catalog/linag3ger/desc.html Ein Probekapitel finden Sie hier: http://www.oreilly.de/catalog/linag3ger/chapter/ Kapitel 4: TCP/IP-Konfiguration (PDF-Format) 2. Mit Open Source-Tools Spam & Viren bekämpfen ================================================ Peter Eisentraut, Alexander Wirt 1. Auflage Juli 2005 ISBN 3-89721-377-X 368 Seiten, EUR 36.00 Systemadministratoren fällt im Kampf gegen Spam und Viren eine Schlüsselrolle zu. Mit Open Source-Tools Spam & Viren bekämpfen behandelt deshalb die aktuellsten Anti-Spam-Strategien, deren Implementierung in die wichtigsten Mail-Programme und erläutert konkrete, erprobte Software-Lösungen auf Open Source-Basis. Die Autoren, die an der Implementierung von großen Spam- und Virenfilterinstallationen für deutsche Behörden und Unternehmen beteiligt waren, vermitteln in dem Buch ihr umfangreiches Detailwissen zur Integration von SpamAssassin, ClamAV, AMaViS, MailScanner, MIMEDefang und Procmail in die bedeutsamsten MTA wie Postfix, Exim und sendmail. Eine ausführliche Beschreibung finden Sie hier: http://www.oreilly.de/catalog/spamvirger/desc.html Ein Probekapitel finden Sie hier: http://www.oreilly.de/catalog/spamvirger/chapter Kapitel 2: Strategien gegen Spam und Viren (PDF-Format) ----------------------------------- Englischsprachige Neuerscheinungen ----------------------------------- 1. Perl Best Practices 2. Perl Testing: A Developer's Notebook 3. Learning Perl, 4th edition 4. Advanced Perl Programming --------------------------------------------------------------------- Tim O'Reillys Antwort auf die Frage: "Is Perl still relevant?" finden Sie hier: http://www.oreillynet.com/pub/a/oreilly/ask_tim/2004/perl_0707.html ---------------------------------------------------------------------- 1. Perl Best Practices ======================== Damian Conway First Edition July 2005 ISBN 0-596-00173-8 544 pages, EUR 38.00 Perl Best Practices offers a collection of 256 guidelines on the art of coding to help you write better Perl code--in fact, the best Perl code you possibly can. The guidelines cover code layout, naming conventions, choice of data and control structures, program decomposition, interface design and implementation, modularity, object orientation, error handling, testing, and debugging. Eine ausführliche Beschreibung finden Sie hier: http://www.oreilly.de/catalog/perlbp/desc.html Ein Probekapitel finden Sie hier: http://www.oreilly.de/catalog/perlbp/chapter/ Chapter 9: Subroutines (PDF Format) 2. Perl Testing: A Developer's Notebook ======================================== Ian Langworth & chromatic First Edition July 2005 ISBN 0-596-10092-2 208 pages, EUR 29.00 Good software testing can increase your productivity, improve your designs, raise your quality, and make you more productive overall. With this series of hands-on labs, you'll learn how Perl's test tools work and how to use them to create basic and complex tests and interpret your results. Perl Testing: A Developer's Notebook is ideal if you want to reduce your software development cycle times. Eine ausführliche Beschreibung finden Sie hier: http://www.oreilly.de/catalog/perltestingadn/desc.html Ein Probekapitel finden Sie hier: http://www.oreilly.de/catalog/perltestingadn/chapter/ Chapter 4: Distributing Your Tests (and Code) (PDF Format) 3. Learning Perl, 4th edition ================================ Randal L. Schwartz, Tom Phoenix & brian d foy Fourth Edition July 2005 ISBN 0-596-10105-8 320 pages, EUR 38.00 Informed by their years of success at teaching Perl as consultants, the authors have re-engineered the Llama to better match the pace and scope appropriate for readers getting started with Perl, while retaining the detailed discussion, thorough examples, and eclectic wit for which the Llama is famous. If you ask Perl programmers today what book they relied on most when they were learning Perl, you'll find that an overwhelming majority will point to the Llama. With good reason. Other books may teach you to program in Perl, but this book will turn you into a Perl programmer. Eine ausführliche Beschreibung finden Sie hier: http://www.oreilly.de/catalog/learnperl4/desc.html Ein Probekapitel finden Sie hier: http://www.oreilly.de/catalog/learnperl4/chapter/ Chapter 11: File Tests (PDF Format) 4. Advanced Perl Programming ============================== Simon Cozens Second Edition July 2005 ISBN 0-596-00456-7 298 pages, EUR 38.00 O'Reilly's most high-level Perl tutorial to date, Advanced Perl Programming, Second Edition teaches you all the complex techniques for production-ready Perl programs. This completely updated guide clearly explains concepts such as introspection, overriding built-ins, extending Perl's object-oriented model, and testing your code for greater stability. Whatever your current level of Perl expertise, this book will help you push your skills to the next level and become a more accomplished programmer. Eine ausführliche Beschreibung finden Sie hier: http://www.oreilly.de/catalog/advperl2/desc.html Ein Probekapitel finden Sie hier: http://www.oreilly.de/catalog/advperl2/chapter/ Chapter 3: Templating Tools (PDF Format) ========================================================= Weitere Fragen und Anforderungen von Rezensionsexemplaren (bitte unter Angabe der gewünschten Lieferanschrift) richten Sie bitte an ug at oreilly.de Coverabbildungen unserer Buecher finden Sie nach ISBN sortiert unter: ftp://ftp.oreilly.de/pub/ora/graphics/book_covers/hi-res/ Bitte lassen Sie uns Belegexemplare/Urls Ihrer Rezensionen zukommen. Vielen Dank! Wenn Sie diesen Informationsservice abbestellen moechten, schicken Sie bitte eine Mail mit folgendem Inhalt an majordomo at oreilly.de: unsubscribe user_groups IHRE-E-MAILADRESSE Tragen Sie diesen Text bitte nicht in die Betreffzeile, sondern in das Mitteilungsfeld des Mailprogramms ein. Wenn Sie Schwierigkeiten haben, wenden Sie sich bitte an listmaster at oreilly.de. ========================================================= O'Reilly Verlag GmbH & Co.KG, Balthasarstr. 81 50670 Koeln Tel.: +(49)-221-9731600 Fax.: +(49)-221-9731608 Geschaeftsfuehrer: Timothy O'Reilly, Elke Hansel Amtsgericht Koeln, HRA 13894, UST-IdNr.: DE 163372785 ----- End forwarded message ----- -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From domm at zsi.at Thu Aug 25 04:49:02 2005 From: domm at zsi.at (Thomas Klausner) Date: Thu, 25 Aug 2005 13:49:02 +0200 Subject: [Vienna-pm] Higher Order Perl Message-ID: <20050825114902.GG23830@domm2.zsi.at> Hi! Ich hab grad ein Review-Exemplar von Higher Order Perl bekommen, dem wirklich sehr interessantem neuen Buch von Mark Jason Dominus http://hop.perl.plover.com/ Ich hab selber allerdings schon im Fruehsommer ein Exemplar gekauft (d.h. vom Buero kaufen lassen). D.h. dass dieses Exemplar an eine interessierte Person weitergegeben wird. Allerdings: Das *&^%%^ Zollpostamt Innsbruck hat 12.60 Euro Zoll verlangt, die ich mal gezahlt habe (wobei ich noch versuchen werde, das Geld zurueckzubekommen, immerhin handelt es sich ja um ein Gratis-Review-Exemplar) Es gaebe als 2 Moeglichkeiten, das Buch zu bekommen: 1) Wer mir als erster 12.60 zukommen laesst, kriegts. 2) Wer das hoechste Gebot (sagen wir mal bis SO, 28.8., 23:59) an die Liste schickt, kriegts. Die Differenz Gebot-12.60 geht an das Vienna.pm-Vereinskonto. -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From domm at zsi.at Thu Aug 25 04:54:52 2005 From: domm at zsi.at (Thomas Klausner) Date: Thu, 25 Aug 2005 13:54:52 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <20050825114902.GG23830@domm2.zsi.at> References: <20050825114902.GG23830@domm2.zsi.at> Message-ID: <20050825115452.GI23830@domm2.zsi.at> Hi! Ach, das hab ich vergessen: Das Buch kostet an sich ~52 Euro, ist also in diesem Fall ein Schnaeppchen! -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From gooly at gmx.at Thu Aug 25 04:40:03 2005 From: gooly at gmx.at (Carl A. Schreiber) Date: Thu, 25 Aug 2005 13:40:03 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <20050825114902.GG23830@domm2.zsi.at> References: <20050825114902.GG23830@domm2.zsi.at> Message-ID: <200508251340.03206.gooly@gmx.at> Thomas, 's w?rd mich schon seh interessieren, k?nnte die 12.60 gleich mit telebanking ?berweisen, aber erst nach Zuschlag.. uawg ;-) Calli Am Donnerstag, 25. August 2005 13:49 schrieb Thomas Klausner: > Hi! > > Ich hab grad ein Review-Exemplar von Higher Order Perl bekommen, dem > wirklich sehr interessantem neuen Buch von Mark Jason Dominus > http://hop.perl.plover.com/ > > Ich hab selber allerdings schon im Fruehsommer ein Exemplar gekauft (d.h. > vom Buero kaufen lassen). > > D.h. dass dieses Exemplar an eine interessierte Person weitergegeben wird. > Allerdings: Das *&^%%^ Zollpostamt Innsbruck hat 12.60 Euro Zoll verlangt, > die ich mal gezahlt habe (wobei ich noch versuchen werde, das Geld > zurueckzubekommen, immerhin handelt es sich ja um ein > Gratis-Review-Exemplar) > > Es gaebe als 2 Moeglichkeiten, das Buch zu bekommen: > > 1) Wer mir als erster 12.60 zukommen laesst, kriegts. > > 2) Wer das hoechste Gebot (sagen wir mal bis SO, 28.8., 23:59) an die Liste > schickt, kriegts. Die Differenz Gebot-12.60 geht an das > Vienna.pm-Vereinskonto. From horshack at lisa.franken.de Thu Aug 25 04:49:15 2005 From: horshack at lisa.franken.de (Richard Lippmann) Date: Thu, 25 Aug 2005 13:49:15 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <20050825115452.GI23830@domm2.zsi.at> References: <20050825114902.GG23830@domm2.zsi.at> <20050825115452.GI23830@domm2.zsi.at> Message-ID: <430DB03B.2070602@lisa.franken.de> "Higher Order Perl". Das Buch ist wirklich sehr gut. Hier liegen auch schon 2 Exemplare rum. Meine Lieblingsstelle ist, wo erkl?rt wird wie man die beliebige Reihenfolge von Elementen einer Liste zusammenstellt (oder mischt). Es wird da eine Art virtueller Kilometerz?hler programmiert, also so ein Drehding f?r Zahlen wie im Auto. Das Beispiel war SO einleuchtend und auch einfach _sch?n_, da? mein Sohn angefangen hat in Perl zu programmieren. Herzlichen Gru? aus N?rnberg Horshack From hjp-vienna-pm-list at hjp.at Thu Aug 25 06:39:42 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Thu, 25 Aug 2005 15:39:42 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <200508251340.03206.gooly@gmx.at> References: <20050825114902.GG23830@domm2.zsi.at> <200508251340.03206.gooly@gmx.at> Message-ID: <20050825133942.GA29084@teal.hjp.at> On 2005-08-25 13:40:03 +0200, Carl A. Schreiber wrote: > 's w?rd mich schon seh interessieren, > > k?nnte die 12.60 gleich mit telebanking ?berweisen, aber erst nach Zuschlag.. > > uawg ;-) Um Angebote wird gebeten? 15! hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050825/67c18d80/attachment.bin From gooly at gmx.at Thu Aug 25 06:44:32 2005 From: gooly at gmx.at (Carl A. Schreiber) Date: Thu, 25 Aug 2005 15:44:32 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <20050825133942.GA29084@teal.hjp.at> References: <20050825114902.GG23830@domm2.zsi.at> <200508251340.03206.gooly@gmx.at> <20050825133942.GA29084@teal.hjp.at> Message-ID: <200508251544.32502.gooly@gmx.at> > Um Angebote wird gebeten? > > 15! ok, 15 von mir, Calli From domm at zsi.at Thu Aug 25 07:06:20 2005 From: domm at zsi.at (Thomas Klausner) Date: Thu, 25 Aug 2005 16:06:20 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <200508251544.32502.gooly@gmx.at> References: <20050825114902.GG23830@domm2.zsi.at> <200508251340.03206.gooly@gmx.at> <20050825133942.GA29084@teal.hjp.at> <200508251544.32502.gooly@gmx.at> Message-ID: <20050825140620.GO23830@domm2.zsi.at> Hi! On Thu, Aug 25, 2005 at 03:44:32PM +0200, Carl A. Schreiber wrote: > > > Um Angebote wird gebeten? > > > > 15! > ok, 15 von mir, Da hiermit wohl die Auktion eroeffnet wurde, musst du mehr als 15 bieten... -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From bernd at firmix.at Thu Aug 25 06:51:20 2005 From: bernd at firmix.at (Bernd Petrovitsch) Date: Thu, 25 Aug 2005 15:51:20 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <200508251544.32502.gooly@gmx.at> References: <20050825114902.GG23830@domm2.zsi.at> <200508251340.03206.gooly@gmx.at> <20050825133942.GA29084@teal.hjp.at> <200508251544.32502.gooly@gmx.at> Message-ID: <1124977881.10628.22.camel@tara.firmix.at> On Thu, 2005-08-25 at 15:44 +0200, Carl A. Schreiber wrote: > > Um Angebote wird gebeten? > > > > 15! > ok, 15 von mir, Das ist weniger wie die vom HJP gebotenen 1307674368000. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From gooly at gmx.at Thu Aug 25 06:55:07 2005 From: gooly at gmx.at (Carl A. Schreiber) Date: Thu, 25 Aug 2005 15:55:07 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <20050825140620.GO23830@domm2.zsi.at> References: <20050825114902.GG23830@domm2.zsi.at> <200508251544.32502.gooly@gmx.at> <20050825140620.GO23830@domm2.zsi.at> Message-ID: <200508251555.07876.gooly@gmx.at> > > > > ok, 15 von mir, > > Da hiermit wohl die Auktion eroeffnet wurde, musst du mehr als 15 bieten... uups, ja, hab's verwechselt, also 16,- Calli From spaceman at foo.at Thu Aug 25 07:51:42 2005 From: spaceman at foo.at (Stefan Weiss) Date: Thu, 25 Aug 2005 16:51:42 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <1124977881.10628.22.camel@tara.firmix.at> References: <20050825114902.GG23830@domm2.zsi.at> <200508251340.03206.gooly@gmx.at> <20050825133942.GA29084@teal.hjp.at> <200508251544.32502.gooly@gmx.at> <1124977881.10628.22.camel@tara.firmix.at> Message-ID: <430DDAFE.9060204@foo.at> On 2005-08-25 15:51, Bernd Petrovitsch wrote: >>> 15! >> ok, 15 von mir, Da wollt ich grad 017 bieten, h?tt sch?n reingepasst, > Das ist weniger wie die vom HJP gebotenen 1307674368000. aber der Bernd passt zu gut auf. Dann halt 17. cheers stefan From gooly at gmx.at Sat Aug 27 01:05:36 2005 From: gooly at gmx.at (Carl A. Schreiber) Date: Sat, 27 Aug 2005 10:05:36 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <430DDAFE.9060204@foo.at> References: <20050825114902.GG23830@domm2.zsi.at> <1124977881.10628.22.camel@tara.firmix.at> <430DDAFE.9060204@foo.at> Message-ID: <200508271005.36980.gooly@gmx.at> Hmm, mal seh'n wer noch da ist, mein neues Gebot 20,00 sch?nes Wochenende, Calli > > aber der Bernd passt zu gut auf. Dann halt 17. From hjp-vienna-pm-list at hjp.at Sat Aug 27 04:54:51 2005 From: hjp-vienna-pm-list at hjp.at (Peter J. Holzer) Date: Sat, 27 Aug 2005 13:54:51 +0200 Subject: [Vienna-pm] Higher Order Perl In-Reply-To: <200508271005.36980.gooly@gmx.at> References: <20050825114902.GG23830@domm2.zsi.at> <1124977881.10628.22.camel@tara.firmix.at> <430DDAFE.9060204@foo.at> <200508271005.36980.gooly@gmx.at> Message-ID: <20050827115451.GB13262@teal.hjp.at> On 2005-08-27 10:05:36 +0200, Carl A. Schreiber wrote: > mal seh'n wer noch da ist, Ich. > mein neues Gebot 20,00 22. hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20050827/32d4ec45/attachment.bin